Op 13-03-2019 om 01:38 schreef Kevin Strasser:
> 64 bpp half float formats are supported on hdr planes only and are subject
> to the following restrictions:
> * 90/270 rotation not supported
> * Yf Tiling not supported
> * Frame Buffer Compression not supported
> * Color Keying not supporte
Am 12.03.19 um 19:02 schrieb Ville Syrjälä:
On Tue, Mar 12, 2019 at 06:37:57PM +0100, Noralf Trønnes wrote:
Den 12.03.2019 18.25, skrev Ville Syrjälä:
On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
On Tue, Mar 12, 2019 at 11:47:04A
On Tue, Mar 12, 2019 at 11:13:03PM +0100, Ahmed S. Darwish wrote:
> Hi,
>
> [[ CCing John for the trylock parts ]]
>
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 11.03.2019 20.23, skrev Daniel Vetter:
> > > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trøn
On Wed, Mar 13, 2019 at 08:49:17AM +0100, John Ogness wrote:
> On 2019-03-12, Ahmed S. Darwish wrote:
> +
> +static void drm_panic_kmsg_dump(struct kmsg_dumper *dumper,
> +enum kmsg_dump_reason reason)
> +{
> +class_for_each_device(d
On Tue, Mar 12, 2019 at 08:02:56PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 12, 2019 at 06:37:57PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 12.03.2019 18.25, skrev Ville Syrjälä:
> > > On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
> > >>
> > >>
> > >> Den 12.03.2019 17.17,
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>
>
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
This adds support for outputting kernel messages on panic().
A kernel mess
== Series Details ==
Series: drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set
URL : https://patchwork.freedesktop.org/series/57882/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5736 -> Patchwork_12441
Den 12.03.2019 23.13, skrev Ahmed S. Darwish:
> Hi,
>
> [[ CCing John for the trylock parts ]]
>
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 11.03.2019 20.23, skrev Daniel Vetter:
>>> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
This ad
== Series Details ==
Series: drm/i915/selftests: Provide stub reset functions
URL : https://patchwork.freedesktop.org/series/57884/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5736 -> Patchwork_12442
Summary
---
**
Quoting Tvrtko Ursulin (2019-03-08 14:33:02)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > +int i915_user_extensions(struct i915_user_extension __user *ext,
> > + const i915_user_extension_fn *tbl,
> > + unsigned long count,
> > + v
On 13/03/2019 10:50, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 14:33:02)
On 08/03/2019 14:12, Chris Wilson wrote:
+int i915_user_extensions(struct i915_user_extension __user *ext,
+ const i915_user_extension_fn *tbl,
+ unsigned long count
Op 13-03-2019 om 08:25 schreef Maarten Lankhorst:
> Op 13-03-2019 om 01:38 schreef Kevin Strasser:
>> 64 bpp half float formats are supported on hdr planes only and are subject
>> to the following restrictions:
>> * 90/270 rotation not supported
>> * Yf Tiling not supported
>> * Frame Buffer
Quoting Tvrtko Ursulin (2019-03-13 11:13:10)
>
> On 13/03/2019 10:50, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-08 14:33:02)
> >>
> >> On 08/03/2019 14:12, Chris Wilson wrote:
> >>> +int i915_user_extensions(struct i915_user_extension __user *ext,
> >>> + const i
Hey Sean and Joonas,
One more pull request for the hdr-formats topic branch. FP16 support
is now also implemented.
Can this be pulled to drm-misc-next and dinq?
~Maarten
topic/hdr-formats-2019-03-13:
Add support for floating point half-width formats.
The following changes since commit 296e9b19e
On 13/03/2019 11:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-13 11:13:10)
On 13/03/2019 10:50, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 14:33:02)
On 08/03/2019 14:12, Chris Wilson wrote:
+int i915_user_extensions(struct i915_user_extension __user *ext,
+
Quoting Tvrtko Ursulin (2019-03-13 11:35:55)
[snip]
> Shall we only reserve some space with a flags and some rsvd fields just
> in case it will need to change/grow?
The only thing that occurs to me is to exchange the next pointer with a
table of next[] (C++ here we come). But I ask myself, could
== Series Details ==
Series: drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set
URL : https://patchwork.freedesktop.org/series/57882/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5736_full -> Patchwork_12441_full
==
On 13/03/2019 11:46, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-13 11:35:55)
[snip]
Shall we only reserve some space with a flags and some rsvd fields just
in case it will need to change/grow?
The only thing that occurs to me is to exchange the next pointer with a
table of next[] (C+
Quoting Tvrtko Ursulin (2019-03-13 13:11:09)
>
> On 13/03/2019 11:46, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-13 11:35:55)
> > [snip]
> >> Shall we only reserve some space with a flags and some rsvd fields just
> >> in case it will need to change/grow?
> >
> > The only thing that
On Sat, 09 Mar 2019, Chris Wilson wrote:
> In the next patch, we will want to update live state within a context.
> As this state may be in use by the GPU and we haven't been explicitly
> tracking its activity, we instead attach it to a request we send down
> the context setup with its new state a
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
> >
> >
> > Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> Th
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
On 2019-03-11 6:42 p.m., Noralf
If a test fails, we quite often mark the device as wedged. Provide the
stub functions so that we can wedge the mock device, and avoid exploding
on test failures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109981
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engi
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
---
drivers/gpu/drm/i915/i915_request.c | 84 +
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.
v2:
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
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
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked i
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
v2: Replace global barrier for swapping over the ppgtt and tlbs with a
local context barrier (Tvrtko)
v3: serialise
If we use the STORE_DATA_INDEX function we can use a fixed offset and
avoid having to lookup up the engine HWS address. A step closer to being
able to emit the final breadcrumb during request_add rather than later
in the submission interrupt handler.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
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.
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we s
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
We only need to acquire a wakeref for ourselves for a few operations, as
most either already acquire their own wakeref or imply a wakeref. In
particular, it is i915_gem_set_wedged() that needed us to present it
with a wakeref, which is incongruous with its "use anywhere" ability.
Suggested-by: Yok
On unpinning the intel_context, we remove it from the active list
inside the GEM context. This list is supposed to be guarded by the GEM
context mutex, so remember to take it!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_context.c | 15 +++
drivers/gpu/drm/i915/
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
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are created and kept alive
until the end of the GEM context. For simplicity, generalise the
requirements and keep an active reference to each HW context.
Signed-off-by: Chris Wilson
--
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a singl
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context
== Series Details ==
Series: drm/i915/selftests: Provide stub reset functions
URL : https://patchwork.freedesktop.org/series/57884/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5736_full -> Patchwork_12442_full
Summary
---
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/vbt: Parse and use the new field
with PSR2 TP2/3 wakeup time
URL : https://patchwork.freedesktop.org/series/57896/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
337a8cd36aa7 drm/i915/vbt: Parse and use the new
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/vbt: Parse and use the new field
with PSR2 TP2/3 wakeup time
URL : https://patchwork.freedesktop.org/series/57896/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/vbt: Parse a
Quoting Chris Wilson (2019-03-13 13:39:33)
> + if (flags & BOND_SCHEDULE) {
> + onstack_fence_init(&fence);
> + err = i915_sw_fence_await_sw_fence_gfp(&rq[0]->submit,
> + &fence,
>
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
If resubmitting the active context, simply skip the submission as
performing the submission from the interrupt handler has higher
throughput than continually provoking lite-restores. If however, we find
ourselves with a new client, we check whether or not we can dequeue into
the second port or to r
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
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
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
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
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 +++---
.../gpu/drm/i915/gem/i915_gem_context_types.h
On unpinning the intel_context, we remove it from the active list
inside the GEM context. This list is supposed to be guarded by the GEM
context mutex, so remember to take it!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_context.c | 15 +++
drivers/gpu/drm/i915/
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 ++
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we s
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/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 52 +++
.../gem/test_i915_gem_ioctls_standalone.c
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
---
drivers/gpu/drm/i915/i915_request.c | 84 +
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
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 | 514
drivers/gpu/drm/i915/ge
If a test fails, we quite often mark the device as wedged. Provide the
stub functions so that we can wedge the mock device, and avoid exploding
on test failures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109981
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engi
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 | 137 +++
drivers/gpu/drm/i915/i915_gem.c | 127
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
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,
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 | 1 +
drivers/gpu/drm/i915/gem/i915_gem_obj
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:
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 | 3 +-
.../gpu/drm/i915/{ => gem}/i915_gem_obj
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
We only need to keep a unique tag for the active lifetime of the
context, and for as long as we need to identify that context. The HW
uses the tag to determine if it should use a lite-restore (why not the
LRCA?) and passes the tag back for various status identifies. The only
status we need to track
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/intel_context_types.h | 2 +-
drivers/gpu/drm/i915/in
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
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 | 116 ++--
1 file changed, 39 insertions(+), 77 deletions(-)
diff --git a/dr
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.
v2:
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
v2: Replace global barrier for swapping over the ppgtt and tlbs with a
local context barrier (Tvrtko)
v3: serialise
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.
If we use the STORE_DATA_INDEX function we can use a fixed offset and
avoid having to lookup up the engine HWS address. A step closer to being
able to emit the final breadcrumb during request_add rather than later
in the submission interrupt handler.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
We only need to acquire a wakeref for ourselves for a few operations, as
most either already acquire their own wakeref or imply a wakeref. In
particular, it is i915_gem_set_wedged() that needed us to present it
with a wakeref, which is incongruous with its "use anywhere" ability.
Suggested-by: Yok
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 | 3 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 285 +
.../test_i915_gem
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are created and kept alive
until the end of the GEM context. For simplicity, generalise the
requirements and keep an active reference to each HW context.
Signed-off-by: Chris Wilson
--
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
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| 764 +
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a singl
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
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked i
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context
Quoting Chris Wilson (2019-03-13 14:43:57)
> 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
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 theme of separating out the GEM clutter.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 25 ++-
.../gpu/drm/i915/{ => gem}/i915_gem_clflush.c | 27 +++
drivers/gpu/drm/i915/gem/i915_gem_clflush.h | 20 +
.../gpu/drm/i915/{
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/vbt: Parse and use the new field
with PSR2 TP2/3 wakeup time
URL : https://patchwork.freedesktop.org/series/57896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5737 -> Patchwork_12443
===
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:02 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 1/7] drm/i915: Readout and check csc_mode
>
>From: Ville Syrjälä
>
>Add t
== Series Details ==
Series: drm/i915: Fix PSR2 selective update corruption after PSR1 setup
URL : https://patchwork.freedesktop.org/series/57900/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Fix PSR2 selective update corruption after PSR1
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:02 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 2/7] drm/i915: Preocmpute/readout/check CHV CGM mode
Typo in precompute
>-Original Message-
>From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:02 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Shankar, Uma ; Roper, Matthew D
>
>Subject: [PATCH 3/7] drm/i915: Extract ilk_csc_limited_range()
>
>From: Ville Syrjälä
>
>
== Series Details ==
Series: skl+ cursor DDB allocation fixes
URL : https://patchwork.freedesktop.org/series/57901/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Accept alloc_size == blocks
Okay!
Commit: drm/i915: Don't pass plane state to
On 2019-03-13 2:37 p.m., Christian König wrote:
> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>> On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
>>> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 11:47
Am 13.03.19 um 16:38 schrieb Michel Dänzer:
On 2019-03-13 2:37 p.m., Christian König wrote:
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
On
On 2019-03-12, Ahmed S. Darwish wrote:
+
+static void drm_panic_kmsg_dump(struct kmsg_dumper *dumper,
+ enum kmsg_dump_reason reason)
+{
+ class_for_each_device(drm_class, NULL, dumper, drm_panic_dev_iter);
>>>
>>> class_for_each_device uses klist
Hi,
[[ CCing John for the trylock parts ]]
On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>
>
> Den 11.03.2019 20.23, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >> This adds support for outputting kernel messages on panic().
> >> A
== Series Details ==
Series: drm/i915: Fix PSR2 selective update corruption after PSR1 setup
URL : https://patchwork.freedesktop.org/series/57900/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5737 -> Patchwork_12444
Summar
On Thu, 07 Mar 2019, Jani Nikula wrote:
> On Thu, 07 Mar 2019, Thomas Preston wrote:
>> Would you like me to resubmit with the suggested changes?
>
> Nah, we can tweak the commit message while applying.
Pushed to dinq, thanks for the patch.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics
== Series Details ==
Series: skl+ cursor DDB allocation fixes
URL : https://patchwork.freedesktop.org/series/57901/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5737 -> Patchwork_12445
Summary
---
**SUCCESS**
No
On 3/13/19 11:54 AM, Christian König wrote:
> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>> On 2019-03-13 2:37 p.m., Christian König wrote:
>>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> On 2019-03-12 6:15 p.m., Noralf Trøn
With direct submission being disabled while the reset in progress, we
have a small window where we may forgo the submission of a new request
and not notice its addition during execlists_reset_finish. To close this
window, always schedule the submission tasklet on coming out of reset to
catch any re
On Wed, Mar 13, 2019 at 03:30:43PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, February 19, 2019 1:02 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: Shankar, Uma ; Roper, Matthew D
> >
> >Subject: [
1 - 100 of 175 matches
Mail list logo
