+Tony to comment on the media-driver views on this.
+Manually re-adding original Cc which did not appear for me from the ML.
On 12/04/2019 07:51, Chris Wilson wrote:
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describ
On 08/04/2019 10:17, Chris Wilson wrote:
Having transitioned GEM over to using intel_context as its primary means
of tracking the GEM context and engine combined and using
i915_request_create(), we can move the older i915_request_alloc()
helper function into selftests/
Signed-off-by: Chris Wi
Quoting Tvrtko Ursulin (2019-04-12 08:02:04)
>
> +Tony to comment on the media-driver views on this.
>
> +Manually re-adding original Cc which did not appear for me from the ML.
>
> On 12/04/2019 07:51, Chris Wilson wrote:
> > SSEU reprogramming of the context introduced the notion of engine cla
== Series Details ==
Series: drm/i915: Introduce struct class_instance for engines across the uAPI
URL : https://patchwork.freedesktop.org/series/59373/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f58592495957 drm/i915: Introduce struct class_instance for engines across the
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describing any engine
beyond the old execbuf interface. We wish to adopt this class:instance
description for more interfaces, so pull it out into a separate type for
userspace co
On 08/04/2019 10:17, Chris Wilson wrote:
It was noted that we made the same mistake for VM_ID as for object
handles, whereby we ensured that we only allocated a single handle for
one ppgtt. This has the unfortunate consequence for userspace that they
need to reference count the handles to avoid
On Fri, Apr 05, 2019 at 02:14:37PM -0700, Radhakrishna Sripada wrote:
> Fixes the clock-gating issue when pipe scaling is enabled.
> (Lineage #2006604312)
>
> V2: Fix typo in headline(Chris)
> Handle the non double buffered nature of the register(Ville)
> V3: Fix checkpatch warning. BAT failur
On Wed, Apr 10, 2019 at 04:53:42PM -0700, Paulo Zanoni wrote:
> This discussion started because we use token pasting in the
> GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
> empty argument to those macros, making the code a little weird. The
> original proposal was to just ad
On Thu, Apr 11, 2019 at 05:33:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On ICL the DMC doesn't reinit combo PHY B so we should not warn
> about its state being bogus during the display core uninit.
>
> Signed-off-by: Ville Syrjälä
Yep, and we'll reinit it manually before using
== Series Details ==
Series: drm/i915: Introduce struct class_instance for engines across the uAPI
(rev2)
URL : https://patchwork.freedesktop.org/series/59373/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5c670eff87cf drm/i915: Introduce struct class_instance for engines acro
On Wed, Apr 10, 2019 at 09:49:33PM -0400, Rob Clark wrote:
> On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom
> wrote:
> >
> > On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> > > On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > > > Generated using make headers_install fro
Use i915_gem_object_lock() to guard the LUT and active reference to
allow us to break free of struct_mutex for handling GEM_CLOSE.
Testcase: igt/gem_close_race
Testcase: igt/gem_exec_parallel
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 75 ++-
Something for the weekend, let's get busy!
Still to go on the per-context-seqno tasks after this are heartbeat
requests -- hmm, actually should be doable with the current state of
i915_request_create (and hopefully I don't need to shoehorn in any more
struct_mutex removal for a patch or two)!
-Chr
Out scatterlist utility routines can be pulled out of i915_gem.h for a
bit more decluttering.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 1 +
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 1 +
drive
---
include/linux/lockdep.h | 4 ++--
kernel/locking/lockdep.c | 15 +--
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 79c3873d58ac..2dc4a61d7355 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep
Continuing the decluttering of i915_gem.c by moving the object busy
checking into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 138 +++
drivers/gpu/drm/i915/i915_gem.c | 128
Continuing the theme of separating out the GEM clutter.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 26 +--
drivers/gpu/drm/i915/Makefile.header-test | 2 -
.../gpu/drm/i915/{ => gem}/i915_gem_clflush.c | 27 +++
drivers/gpu/drm/i915/gem/i
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
An old optimisation to reduce the number of atomics per batch sadly
relies on struct_mutex for coordination. In order to remove struct_mutex
from serialising object/context closing, always taking and releasing an
active reference on first use / last use greatly simplifies the locking.
Signed-off-b
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
v2: s/setup_xcs/setup_common/ for intel_ring_submission_setup()
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Urs
We no longer need to track the active intel_contexts within each engine,
allowing us to drop a tricky mutex_lock from inside unpin (which may
occur inside fs_reclaim).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 11 +--
drivers/gpu/drm/i915/gt/inte
Allow the user to direct which physical engines of the virtual engine
they wish to execute one, as sometimes it is necessary to override the
load balancing algorithm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 58 +++
drivers/gpu/drm/i915/gt/selftest_lrc.c
The SINGLE_TIMELINE flag can be used to create a context such that all
engine instances within that context share a common timeline. This can
be useful for mixing operations between real and virtual engines, or
when using a composite context for a single client API context.
Signed-off-by: Chris Wi
Our eventual goal is to rid request construction of struct_mutex, with
the short term step of lifting the struct_mutex requirements into the
higher levels (i.e. the caller must ensure that the context is already
pinned into the GTT). In this patch, we pin GVT's shadow context upon
allocation and so
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. This first/last access needs serialisation and so
we encompass a mutex with the regular intel_wakeref_t tracker.
v2: Drop the _once n
We no longer track the execution order along the engine and so no longer
need to enforce ordering of retire along the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 128 +++-
1 file changed, 52 insertions(+), 76 deletions(-)
diff --git a/dr
When using a global seqno, we required a precise stop-the-workd event to
handle preemption and unwind the global seqno counter. To accomplish
this, we would preempt to a special out-of-band context and wait for the
machine to report that it was idle. Given an idle machine, we could very
precisely s
Having hid the partially exposed new ABI from the PR, put it back again
for completion of context recovery. A significant part of context
recovery is the ability to reuse as much of the old context as is
feasible (to avoid expensive reconstruction). The biggest chunk kept
hidden at the moment is fi
As we push for better compartmentalisation, it is more convenient to
copy the default sseu configuration from the engine into the derived
logical context, than it is to dig it out from i915->runtime_info.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
driv
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describing any engine
beyond the old execbuf interface. We wish to adopt this class:instance
description for more interfaces, so pull it out into a separate type for
userspace co
Start partitioning off the code that talks to the hardware (GT) from the
uapi layers and move the device facing code under gt/
One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to
subdivide that header and body further (and split out the submission
code from the ringbuffer and log
Continuing the decluttering of i915_gem.c, that of the read/write
domains, perhaps the biggest of GEM's follies?
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 784 +
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine,
Rename the engine this HW context is currently active upon (that we are
flying upon) to disambiguate between the mixture of different active
terms (and prevent conflict in future patches).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
drivers/gpu/drm/i915
Continuing the decluttering of i915_gem.c by moving the client self
throttling into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 74
drivers/gpu/drm/i915/i915_drv.h
For convenience in avoiding inline spaghetti, keep the type definition
as a separate header.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/Makefile | 5 +
drivers/gpu/drm/i915/gem/Makefile.
Start acquiring the logical intel_context and using that as our primary
means for request allocation. This is the initial step to allow us to
avoid requiring struct_mutex for request allocation along the
perma-pinned kernel context, but it also provides a foundation for
breaking up the complex requ
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW context. Just
allocate a logical per-engine
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpo
Continuing the decluttering of i915_gem.c by moving the object wait
decomposition into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 +
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 276 ++
Continuing the decluttering of i915_gem.c, now the turn of do_mmap and
the faulthandlers
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 505
drivers/gpu/drm/i915/ge
Use the per-object local lock to control the cache domain of the
individual GEM objects, not struct_mutex. This is a huge leap forward
for us in terms of object-level synchronisation; execbuffers are
coordinated using the ww_mutex and pread/pwrite is finally fully
serialised again.
Signed-off-by:
drivers/gpu/drm/i915/intel_pm.c:8352:9: error: incompatible types in comparison
expression (different address spaces)
drivers/gpu/drm/i915/intel_pm.c:8359:9: error: incompatible types in comparison
expression (different address spaces)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel
Move the intel_context_instance() to the caller so that we can decouple
ourselves from one context instance per engine.
v2: Rename pin_lock() to lock_pinned(), hopefully that is clearer.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c |
Split out the powermanagement portion (GT wakeref, suspend/resume) of
GEM from i915_gem.c into its own file.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the h
Continuing the decluttering of i915_gem.c, this time the legacy physical
object.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +
.../gpu/drm/i915/gem/i915_gem_object_types.h
Simply the setup slightly for the sseu selftests to use the actual
kernel_context.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i
We want to pass in a intel_context into intel_context_pin() and that
requires us to first be able to lookup the intel_context!
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c| 37 +++---
drivers/gpu/drm/i915/gt/intel_contex
Combine the (i915_gem_context, intel_engine) into a single parameter,
the intel_context for convenience and later simplification.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 74 +++
1 file changed, 44 insertions(+),
It was noted that we made the same mistake for VM_ID as for object
handles, whereby we ensured that we only allocated a single handle for
one ppgtt. This has the unfortunate consequence for userspace that they
need to reference count the handles to avoid destroying an active ID. If
we allow multipl
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
In order to separate the reservation phase of building a request from
its emission phase, we need to pull some of the request alloc activities
from deep inside i915_request to the surface, GEM_EXECBUFFER.
v2: Be frivolous, use a local drm_i915_private..
Signed-off-by: Chris Wilson
Reviewed-by: T
Split the plain old shmem object into its own file to start decluttering
i915_gem.c
v2: Lose the confusing, hysterical raisins, suffix of _gtt.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ob
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that w
We wish to start segregating the power management into different control
domains, both with respect to the hardware and the user interface. The
first step is that at the lowest level flow of requests, we want to
process a context event (and not a global GEM operation). In this patch,
we introduce t
Currently the code for manipulating the pages on an object is still
residing in i915_gem.c, move it to i915_gem_object.c
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/gem/Makefile
On Thu, Apr 11, 2019 at 07:20:32AM +0100, Eric Engestrom wrote:
> On Wednesday, 2019-04-10 21:49:33 -0400, Rob Clark wrote:
> > On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom
> > wrote:
> > > > > diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
> > > > > index c06d0a5..91a16b3 100644
> >
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual
Declutter i915_drv/gem.h by moving the ioctl API into its own header.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 52 ++
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_drv.h|
Having transitioned GEM over to using intel_context as its primary means
of tracking the GEM context and engine combined and using
i915_request_create(), we can move the older i915_request_alloc()
helper function into selftests/ where the remaining users are confined.
Signed-off-by: Chris Wilson
== Series Details ==
Series: drm: Add detection of changing of edid on between suspend and resume
(rev2)
URL : https://patchwork.freedesktop.org/series/59352/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8cadfc318c07 drm: Add detection of changing of edid on between suspend a
This series adds support for programmable gamma modes and
exposes a property interface for the same. Also added,
support for multi segment gamma mode introduced in ICL+
It creates GAMMA_MODE property interface. This is an enum
property with values as blob_id's and exposes
the various gamma modes s
From: Ville Syrjälä
Add a gamma mode property to enable various kind of
gamma modes supported by platforms like: Interpolated, Split,
Multi Segmented etc. Userspace can get this property and
should be able to get the platform capabilties wrt various
gamma modes possible and the possible ranges.
Add macros to define multi segmented gamma registers
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c206e8..5554b0c 100644
--- a/drivers
Attach the gamma mode property to allow userspace
set the gamma mode and provide the luts for the
same.
v2: Enabled just 1 property interface for gamma_mode,
as suggested by Ville.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 3 +++
drivers/gpu/drm/i915/intel_display.c
From: Ville Syrjälä
This defines the color lut ranges for 10bit and multi
segmented gamma range for ICL.
v2: Defined and advertise the gamma modes supported on
various platforms as suggested by Ville.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_colo
Introduced a client cap for advance cap mode
capability. Userspace should set this to get
to be able to use the new gamma_mode property.
If this is not set, driver will work in legacy
mode.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
dr
Gen11 introduced a new gamma mode i.e, multi segmented
gamma mode. Added support for the same.
v2: Aligned to just 1 property interface as suggested by
Ville. Fixed Ville's review comments.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 166 +
Enable advance gamma modes based on client
caps.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index edf5ff8..36604c16
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not
On Fri, 12 Apr 2019, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig beh
== Series Details ==
Series: series starting with [01/50] drm/i915: Introduce struct class_instance
for engines across the uAPI
URL : https://patchwork.freedesktop.org/series/59379/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7cdd4a7000d1 drm/i915: Introduce struct class_ins
== Series Details ==
Series: series starting with [01/50] drm/i915: Introduce struct class_instance
for engines across the uAPI
URL : https://patchwork.freedesktop.org/series/59379/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Introduce st
== Series Details ==
Series: Add Multi Segment Gamma Support (rev3)
URL : https://patchwork.freedesktop.org/series/58169/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d60e638b9241 drm: Add gamma mode property
938ac10de262 drm/i915: Define color lut range structure
-:28: ERROR:
== Series Details ==
Series: drm/i915/ehl: Inherit Ice Lake conditional code
URL : https://patchwork.freedesktop.org/series/59364/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5917_full -> Patchwork_12770_full
Summary
The HW resets it CSB tail pointer on resetting the engine. Most of the
time. In case it doesn't (and for system resume) we write the expected
value anyway. For extra paranoia, flush the write before we invalidate
the cacheline.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i
== Series Details ==
Series: drm/i915/ehl: Add support for DPLL4 (v3) (rev2)
URL : https://patchwork.freedesktop.org/series/59078/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5917_full -> Patchwork_12771_full
Summary
On 11/04/2019 11:44, Michal Wajdeczko wrote:
> Some CI systems might be configured to run with no longer supported
> configuration "enable_guc=3" or "enable_guc=1". Hack that ;)
This is not a hack, this is what we need to do: Users put parameters in
their command line and forget about them, myself
== Series Details ==
Series: drm/i915: Introduce struct class_instance for engines across the uAPI
(rev2)
URL : https://patchwork.freedesktop.org/series/59373/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5922 -> Patchwork_12773
==
== Series Details ==
Series: drm/i915: Suppress spurious combo PHY B warning
URL : https://patchwork.freedesktop.org/series/59350/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5916_full -> Patchwork_12766_full
Summary
== Series Details ==
Series: drm/i915: Don't call bxt_ddi_phy_calc_lane_lat_optim_mask() after
failing intel_dp_compute_config() (rev2)
URL : https://patchwork.freedesktop.org/series/59351/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5917_full -> Patchwork_12768_full
==
== Series Details ==
Series: drm/i915/ehl: Inherit Ice Lake conditional code
URL : https://patchwork.freedesktop.org/series/59364/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5917_full -> Patchwork_12770_full
Summary
On Fri, 12 Apr 2019 13:30:47 +0200, Martin Peres
wrote:
On 11/04/2019 11:44, Michal Wajdeczko wrote:
Some CI systems might be configured to run with no longer supported
configuration "enable_guc=3" or "enable_guc=1". Hack that ;)
This is not a hack, this is what we need to do: Users put pa
== Series Details ==
Series: drm: Add detection of changing of edid on between suspend and resume
(rev2)
URL : https://patchwork.freedesktop.org/series/59352/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5922 -> Patchwork_12774
===
On 12/04/2019 08:14, Chris Wilson wrote:
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describing any engine
beyond the old execbuf interface. We wish to adopt this class:instance
description for more interfaces, so pull
== Series Details ==
Series: series starting with [01/50] drm/i915: Introduce struct class_instance
for engines across the uAPI
URL : https://patchwork.freedesktop.org/series/59379/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5922 -> Patchwork_12775
Quoting Patchwork (2019-04-12 13:11:02)
> == Series Details ==
>
> Series: series starting with [01/50] drm/i915: Introduce struct
> class_instance for engines across the uAPI
> URL : https://patchwork.freedesktop.org/series/59379/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes
Chris Wilson writes:
> The HW resets it CSB tail pointer on resetting the engine. Most of the
> time. In case it doesn't (and for system resume) we write the expected
> value anyway. For extra paranoia, flush the write before we invalidate
> the cacheline.
>
> Signed-off-by: Chris Wilson
> Cc: M
Quoting Mika Kuoppala (2019-04-12 13:22:12)
> Chris Wilson writes:
>
> > The HW resets it CSB tail pointer on resetting the engine. Most of the
> > time. In case it doesn't (and for system resume) we write the expected
> > value anyway. For extra paranoia, flush the write before we invalidate
> >
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-04-12 13:22:12)
>> Chris Wilson writes:
>>
>> > The HW resets it CSB tail pointer on resetting the engine. Most of the
>> > time. In case it doesn't (and for system resume) we write the expected
>> > value anyway. For extra paranoia, flush the
== Series Details ==
Series: Add Multi Segment Gamma Support (rev3)
URL : https://patchwork.freedesktop.org/series/58169/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5922 -> Patchwork_12776
Summary
---
**FAILURE**
On 12/04/2019 09:53, Chris Wilson wrote:
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. This first/last access needs serialisation and so
we encompass a mutex with the regular in
On 12/04/2019 09:53, Chris Wilson wrote:
We wish to start segregating the power management into different control
domains, both with respect to the hardware and the user interface. The
first step is that at the lowest level flow of requests, we want to
process a context event (and not a global G
Quoting Tvrtko Ursulin (2019-04-12 13:59:30)
>
> On 12/04/2019 09:53, Chris Wilson wrote:
> > For controlling runtime pm of the GT and engines, we would like to have
> > a callback to do extra work the first time we wake up and the last time
> > we drop the wakeref. This first/last access needs se
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpo
On 12/04/2019 09:53, Chris Wilson wrote:
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW
On Fri, Apr 12, 2019 at 11:29:17AM +0300, Imre Deak wrote:
> On Thu, Apr 11, 2019 at 05:33:49PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On ICL the DMC doesn't reinit combo PHY B so we should not warn
> > about its state being bogus during the display core uninit.
> >
> > Sign
1 - 100 of 192 matches
Mail list logo
