== Series Details ==
Series: series starting with [v4,1/2] drm/i915/selftests: Verify context
workarounds (rev3)
URL : https://patchwork.freedesktop.org/series/60857/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13062
===
On 21/05/2019 18:17, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 17:50:30)
On 21/05/2019 17:36, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977
== Series Details ==
Series: series starting with [1/4] mm: Check if mmu notifier callbacks are
allowed to fail (rev2)
URL : https://patchwork.freedesktop.org/series/60874/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b2f1812e79cc mm: Check if mmu notifier callbacks are allow
On 21/05/2019 18:48, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 18:19:50)
On 21/05/2019 18:07, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
+ if (eb->oa_config &&
+ eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the
== Series Details ==
Series: series starting with [1/4] mm: Check if mmu notifier callbacks are
allowed to fail (rev2)
URL : https://patchwork.freedesktop.org/series/60874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13063
=
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60921/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e58657ffae31 drm/i915: Make sandybridge_pco
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60921/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make s
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60921/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13064
==
Hi Jani,
On Mon, Apr 29, 2019 at 03:29:36PM +0300, Jani Nikula wrote:
> It used to be handy that we only had a couple of headers, but over time
> intel_drv.h has become unwieldy. Extract declarations to a separate
> header file corresponding to the implementation module, clarifying the
> modularit
On Fri, 2019-05-17 at 09:17 -0700, Rodrigo Vivi wrote:
> On Thu, May 16, 2019 at 03:49:19PM +, Summers, Stuart wrote:
> > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote:
> > > On Thu, 16 May 2019, "Summers, Stuart"
> > > wrote:
> > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote
Some steps in gen6_alloc_va_range require the HW to be awake, so ideally
we should be grabbing the wakeref ourselves and not relying on the
caller already holding it for us.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c
The plan is to use the blitter engine for async object clearing when
using local memory, but before we can move the worker to get_pages() we
have to first tame some more of our struct_mutex usage. With this in
mind we should be able to upstream the object clearing as some
selftests, which should se
On Fri, May 17, 2019 at 09:02:46AM -, Patchwork wrote:
> == Series Details ==
>
> Series: C: Revert "net/sch_generic: Shut up noise"
> URL : https://patchwork.freedesktop.org/series/60758/
> State : success
Discussed with Martin on irc, he's ok with us dropping this one. There's
still a cib
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60930/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c2a5e301596f drm/i915/gtt: grab wakeref in gen6_alloc_va_range
dd9e0
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60930/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gtt: grab wakeref in gen6_alloc_
On 2019/05/21 23:44, Daniel Vetter wrote:
OOM notifiers should not depend on any locks or sleepable conditionals.
If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
it will deadlock. Thus, despite blocking API, this should effectively be
non-blocking. All OOM
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
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
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
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
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
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
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
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.
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.
v2: Only kick the virtual engines on context-out if required
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko
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: series starting with [v3,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13065
===
Hi Joonas,
On Tue, 21 May 2019 16:04:16 +0300 Joonas Lahtinen
wrote:
>
> We also have an incoming patch where the Fixes: line has a comment in
> it. Does your tooling account for this when checking the Fixes: line?
I will make sure mine does.
--
Cheers,
Stephen Rothwell
pgpcXXON36fiK.pgp
De
Quoting Matthew Auld (2019-05-21 21:42:35)
> +static void clear_pages_signal_irq_worker(struct irq_work *work)
> +{
> + struct clear_pages_work *w = container_of(work, typeof(*w), irq_work);
> +
> + dma_fence_signal(&w->dma);
> + dma_fence_put(&w->dma);
> +}
> +
> +static void cle
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60931/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a7f0011a8006 drm/i915: Restore control over ppgtt for
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60931/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Restore control o
On Tue, May 21, 2019 at 04:24:58PM +0300, Ville Syrjälä wrote:
> On Mon, May 20, 2019 at 04:25:41PM -0700, Khaled Almahallawy wrote:
> > According to DP 1.4 standard, if the source supports four pre-emphasis
> > levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only
> > when
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60931/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6115 -> Patchwork_13066
=
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190521]
[cannot apply to v5.2-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6113_full -> P
On Wed 22-05-19 06:06:31, Tetsuo Handa wrote:
[...]
> Since OOM notifier will be called after shrinkers are attempted,
> can i915 move from OOM notifier to shrinker?
That would be indeed preferable. OOM notifier is an API from hell.
--
Michal Hocko
SUSE Labs
_
101 - 136 of 136 matches
Mail list logo
