== Series Details ==
Series: series starting with [1/9] drm/i915/gvt: Pin the per-engine GVT shadow
contexts
URL : https://patchwork.freedesktop.org/series/59970/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gvt: Pin the per-engine GVT shad
== Series Details ==
Series: series starting with [1/9] drm/i915/gvt: Pin the per-engine GVT shadow
contexts
URL : https://patchwork.freedesktop.org/series/59970/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
800faa589858 drm/i915/gvt: Pin the per-engine GVT shadow contexts
14
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix fastset vs. pfit on/off on HSW
EDP transcoder
URL : https://patchwork.freedesktop.org/series/59950/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6000_full -> Patchwork_12876_full
==
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
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
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 |
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 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
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(+),
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
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
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 11 +--
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
Quoting Zhenyu Wang (2019-04-26 07:04:45)
> On 2019.04.25 17:23:44 +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-04-25 06:42:02)
> > > Our eventual goal is to rid request construction of struct_mutex, with
> > > the short term step of lifting the struct_mutex requirements into the
> > >
== Series Details ==
Series: series starting with [01/10] drm/i915: Seal races between async GPU
cancellation, retirement and signaling (rev2)
URL : https://patchwork.freedesktop.org/series/59912/
State : failure
== Summary ==
Applying: drm/i915: Seal races between async GPU cancellation, ret
On 2019.04.25 17:23:44 +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-04-25 06:42:02)
> > 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
On 2019.04.25 17:23:44 +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-04-25 06:42:02)
> > 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
== Series Details ==
Series: drm/i915: Clean up cherryview_load_luts() (rev2)
URL : https://patchwork.freedesktop.org/series/59169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5999_full -> Patchwork_12874_full
Summary
---
Daniel, drm-misc-next-fixes?
Dave.
On Fri, 26 Apr 2019 at 12:25, wrote:
>
> Hi Dave,
>
> > -Original Message-
> > From: Dave Airlie [mailto:airl...@gmail.com]
> > Sent: Friday, April 26, 2019 11:19 AM
> > To: Yamada, Masahiro/山田 真弘
> > Cc: David Airlie ; Daniel Vetter ;
> > dri-devel ;
Hi Dave,
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Friday, April 26, 2019 11:19 AM
> To: Yamada, Masahiro/山田 真弘
> Cc: David Airlie ; Daniel Vetter ;
> dri-devel ; nouveau
> ; Sam Ravnborg ; David
> (ChunMing) Zhou ; amd-gfx mailing list
> ; James (Qian) W
On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
wrote:
>
> Hi.
>
>
> On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> wrote:
> >
> > Currently, the Kbuild core manipulates header search paths in a crazy
> > way [1].
> >
> > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> >
== Series Details ==
Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color
(rev7)
URL : https://patchwork.freedesktop.org/series/58912/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6001 -> Patchwork_12881
===
Hi.
On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
wrote:
>
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> tha
== Series Details ==
Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color
(rev7)
URL : https://patchwork.freedesktop.org/series/58912/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40c9882274e6 drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit d
From: Clinton Taylor
v2: Fix commit msg to reflect why issue occurs(Jani)
Set GCP_COLOR_INDICATION only when we set 10/12 bit deep color.
Changing settings from 10/12 bit deep color to 8 bit(& vice versa)
doesn't work correctly using xrandr max bpc property. When we
connect a monitor which suppo
On Thu, Apr 25, 2019 at 11:16:33PM +0100, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2019-04-25 22:50:37)
> > No functional change. But by making those bits together
> > we will be able to convert many functions to pass
> > intel_irq instead of i915_private or uncore.
> >
> > For gen8+ "gt_" pref
== Series Details ==
Series: series starting with [1/7] drm/i915: Introduce intel_irq
URL : https://patchwork.freedesktop.org/series/59958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6000 -> Patchwork_12880
Summary
-
Subslice stride and EU stride are calculated multiple times in
i915_query. Move this calculation to a macro to reduce code duplication.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_query.c | 17 -
drivers/gpu/drm/i915/intel_sseu.h | 1 +
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice i
Add a new function to return the number of subslices per slice to
consolidate code usage.
v2: rebase on changes to move sseu struct to intel_sseu.h
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_device_in
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/intel_device_info.h | 47
drivers/gpu/drm/i915/intel_sseu.h| 47
2 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gp
In the GETPARAM ioctl handler, use a local variable to consolidate
usage of SSEU runtime info.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_d
This patch series contains a few code clean-up patches, followed
by a patch which changes the storage of the subslice mask to better
match the userspace access through the I915_QUERY_TOPOLOGY_INFO
ioctl. The index into the subslice_mask array is then calculated:
slice * subslice stride + subslice
== Series Details ==
Series: series starting with [1/7] drm/i915: Introduce intel_irq
URL : https://patchwork.freedesktop.org/series/59958/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Introduce intel_irq
-drivers/gpu/drm/i915/selftests/../
Quoting Rodrigo Vivi (2019-04-25 22:50:37)
> No functional change. But by making those bits together
> we will be able to convert many functions to pass
> intel_irq instead of i915_private or uncore.
>
> For gen8+ "gt_" prefix would be better than pm_ on them
> since these regs include more stuff
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling (rev2)
URL : https://patchwork.freedesktop.org/series/59933/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5999_full -> Patchwork_12873_full
The plan is to convert most of arguments to use intel_irq
instead of intel_uncore or i915.
Note that dev_priv is not getting replaced by i915 because
the plan also includes to move dev_priv to intel_irq.
The caveat is that we will need the uncore for tracking
the mmio region that we need, but at
No functional change. But by making those bits together
we will be able to convert many functions to pass
intel_irq instead of i915_private or uncore.
For gen8+ "gt_" prefix would be better than pm_ on them
since these regs include more stuff then PM, but let's
keep for legacy reasons.
Signed-off
Let's start the re-org of irqs with the introduction of intel_irq
structure.
Since irq_lock is used everywhere let's start intel_irq with
this lock first.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 8 +-
drivers/gpu/drm/i915/i915_debugfs.c | 8 +-
Now that we are free from passing uncore around let's free ourselves
from passing the whole i915 reference and only passing the struct
with all information that we need for handling the interrupts.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_irq.c | 57 +
Another step towards the consolidation of all irq
related stuff under new intel_irq
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 16 ++---
drivers/gpu/drm/i915/i915_drv.h| 14 ++--
drivers/gpu/drm/i915/i915_irq.c| 76 +++---
Let's continue the migration starting from newer to older platforms.
The goal is to use intel_irq struct and intel_uncore_* functions
along all i915_irq.c as much as possible.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_irq.c | 38 +++--
1 file changed,
Let's continue the IRQ consolidation with display_irqs_enabled.
Another possibility was a full split on gt_irq vs de_irq,
but for now display_irqs_enabled is already protected
buy the same lock. So, at least for now, let's keep
them together.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915
== Series Details ==
Series: drm/i915: Fix 90/270 degree rotated RGB565 src coord checks
URL : https://patchwork.freedesktop.org/series/59956/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6000 -> Patchwork_12879
Summary
--
== Series Details ==
Series: drm/i915: Fix 90/270 degree rotated RGB565 src coord checks
URL : https://patchwork.freedesktop.org/series/59956/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Fix 90/270 degree rotated RGB565 src coord checks
-O
== Series Details ==
Series: drm/i915: Fix 90/270 degree rotated RGB565 src coord checks
URL : https://patchwork.freedesktop.org/series/59956/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
232156a1c178 drm/i915: Fix 90/270 degree rotated RGB565 src coord checks
-:42: CHECK:MULT
On Wed, Apr 17, 2019 at 12:57:44PM +0300, Jani Nikula wrote:
> On Fri, 05 Apr 2019, Aditya Swarup wrote:
> > From: Clinton Taylor
> >
> > v2: Fix commit msg to reflect why issue occurs(Jani)
> > Set GCP_COLOR_INDICATION only when we set 10/12 bit deep color.
> >
> > Changing settings from 10/12 b
From: Ville Syrjälä
Supposedly both src coordinates have to even when doing 90/270
degree rotation with RGB565. This is definitely true for the
X coordinate (we just get a black screen when it is odd). My
experiments didn't show any misbehaviour with an odd
Y coordinate, but let's trust the spec
== Series Details ==
Series: drm/i915: Fix ICL output CSC programming
URL : https://patchwork.freedesktop.org/series/59955/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6000 -> Patchwork_12878
Summary
---
**SUCCESS*
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/icl: Factor out combo PHY lane
power setup helper
URL : https://patchwork.freedesktop.org/series/59954/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6000 -> Patchwork_12877
==
From: Ville Syrjälä
When I refactored the code into its own function I accidentally
misplaced the <<16 shifts for some of the registers causing us
to lose the blue channel entirely.
We should really find a way to test this...
Cc: Uma Shankar
Fixes: d2c19b06d6ea ("drm/i915: Clean up ilk/icl pip
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/icl: Factor out combo PHY lane
power setup helper
URL : https://patchwork.freedesktop.org/series/59954/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/icl: Factor out combo P
Factor out the combo PHY lane power configuration code to a separate
helper; it will be also needed by the next patch adding the same
configuration for DDI ports.
Add support for DDI ports and lane reversal as preparation for the next
patch.
The PWR_DOWN_LN_1 value is unspecified in the BSpec reg
This step of the BSpec combo PHY port enabling is missing, so add it
now.
v2:
- Rebased on the new fixed v2 version of the helper.
Reported-by: Ville Syrjala
Cc: Jani Nikula
Cc: Madhav Chauhan
Cc: Ville Syrjala
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 9 +
1 f
On Mon, Apr 22, 2019 at 10:27:14AM -0300, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
This is massively CCed covering a large range of subsystems and is patch
25 of a 79 patch series so I've no context for what's going on here or
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix fastset vs. pfit on/off on HSW
EDP transcoder
URL : https://patchwork.freedesktop.org/series/59950/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6000 -> Patchwork_12876
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice i
This patch series contains a few code clean-up patches, followed
by a patch which changes the storage of the subslice mask to better
match the userspace access through the I915_QUERY_TOPOLOGY_INFO
ioctl. The index into the subslice_mask array is then calculated:
slice * subslice stride + subslice
From: Ville Syrjälä
On HSW the pipe A panel fitter lives inside the display power well,
and the input MUX for the EDP transcoder needs to be configured
appropriately to route the data through the power well as needed.
Changing the MUX setting is not allowed while the pipe is active,
so we need to
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/intel_device_info.h | 47
drivers/gpu/drm/i915/intel_sseu.h| 47
2 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gp
Add a new function to return the number of subslices per slice to
consolidate code usage.
v2: rebase on changes to move sseu struct to intel_sseu.h
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_device_in
In the GETPARAM ioctl handler, use a local variable to consolidate
usage of SSEU runtime info.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_d
From: Ville Syrjälä
Convert the HSW pch_pfit.force_thru to a proper state variable
with readout and accompanying pipe conf check. Makes the logic
a bit more straightforward, and hopefully prevents some
breakage in the future.
'force_thru' is probably not the best name for this, but I
didn't mana
Subslice stride and EU stride are calculated multiple times in
i915_query. Move this calculation to a macro to reduce code duplication.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_query.c | 17 -
drivers/gpu/drm/i915/intel_sseu.h | 1 +
Quoting Chris Wilson (2019-04-25 06:42:02)
> 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,
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev5)
URL : https://patchwork.freedesktop.org/series/58597/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5996_full -> Patchwork_12870_full
Su
== Series Details ==
Series: stacktrace: Consolidate stack trace usage (rev3)
URL : https://patchwork.freedesktop.org/series/59699/
State : failure
== Summary ==
Applying: tracing: Cleanup stack trace code
error: sha1 information is lacking or useless (include/linux/ftrace.h).
error: could not
== Series Details ==
Series: drm/i915: Clean up cherryview_load_luts() (rev2)
URL : https://patchwork.freedesktop.org/series/59169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5999 -> Patchwork_12874
Summary
---
**
On Thu, Apr 25, 2019 at 11:45:11AM +0200, Thomas Gleixner wrote:
> There is only one caller which hands in save_trace as function pointer.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
___
Intel-gfx mailing list
Intel-gfx@lists.f
On Thu, Apr 25, 2019 at 11:45:17AM +0200, Thomas Gleixner wrote:
> Simplify the stack retrieval code by using the storage array based
> interface.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Steven Rostedt (VMware)
> ---
> kernel/trace/trace_stack.c | 37
On Thu, Apr 25, 2019 at 11:44:53AM +0200, Thomas Gleixner wrote:
> This is an update to V2 which can be found here:
>
> https://lkml.kernel.org/r/20190418084119.056416...@linutronix.de
>
> Changes vs. V2:
>
> - Fixed the kernel-doc issue pointed out by Mike
>
> - Removed the '-1' oddity f
On Thu, Apr 25, 2019 at 11:45:14AM +0200, Thomas Gleixner wrote:
> @@ -2788,29 +2798,32 @@ static void __ftrace_trace_stack(struct
>*/
> preempt_disable_notrace();
>
> - use_stack = __this_cpu_inc_return(ftrace_stack_reserve);
> + stackidx = __this_cpu_inc_return(ftrace_stac
Hi Daniel, Dave,
Here is a new drm-misc-fixes PR.
Thanks!
Maxime
drm-misc-fixes-2019-04-25:
- sun4i: Fix module loading / unloading
- vc4: Fix a compilation error and memory leak
- dw-hdmi: Fix an overflow on Rockchip and SCDC configuration
The following changes since commit 1a07a94b47b1f528f39c
== Series Details ==
Series: drm/i915: Explicitly pin the logical context for execbuf
URL : https://patchwork.freedesktop.org/series/59911/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5994_full -> Patchwork_12866_full
Sum
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling (rev2)
URL : https://patchwork.freedesktop.org/series/59933/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5999 -> Patchwork_12873
=
On Wed, 17 Apr 2019, Swati Sharma wrote:
> v3: Rebase
> v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() (Jani)
> -Added the default label above the correct label (Jani)
> -Corrected smatch warn "variable dereferenced before check" (Dan
> Carpenter)
>
> Signed-off-by: Swa
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling (rev2)
URL : https://patchwork.freedesktop.org/series/59933/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i91
On Wed, 17 Apr 2019, Swati Sharma wrote:
> Thanks to Jani N, Matt and Ville for the review comments. Hopefully
> I have addressed all the current review comments and ready to receive
> more :)
Sorry to take for so long to notice... but all of the patches need a
proper commit message. It doesn't h
Quoting Tvrtko Ursulin (2019-04-25 13:14:00)
>
> On 25/04/2019 10:19, Chris Wilson wrote:
> > 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 t
On 25/04/2019 10:19, Chris Wilson wrote:
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
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling (rev2)
URL : https://patchwork.freedesktop.org/series/59933/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d5f35de3a4aa drm/i915: Seal races
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling
URL : https://patchwork.freedesktop.org/series/59933/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5999 -> Patchwork_12871
== Series Details ==
Series: stacktrace: Consolidate stack trace usage (rev2)
URL : https://patchwork.freedesktop.org/series/59699/
State : failure
== Summary ==
Applying: tracing: Cleanup stack trace code
error: sha1 information is lacking or useless (include/linux/ftrace.h).
error: could not
Den 25.04.2019 11.25, skrev Daniel Vetter:
> On Thu, Apr 25, 2019 at 10:31 AM Noralf Trønnes wrote:
>>
>> The Intel CI [1] was not happy with the previous version and I don't
>> know which part it didn't like. So I'll split up the series and feed it
>> piece by piece until I know where the probl
On 25/04/2019 12:29, Chris Wilson wrote:
Make the engine responsible for cleaning itself up!
This removes the i915->gt.cleanup vfunc that has been annoying the
casual reader and myself for the last several years, and helps keep a
future patch to add more cleanup tidy.
v2: Assert that engine->d
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling
URL : https://patchwork.freedesktop.org/series/59933/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Seal
Make the engine responsible for cleaning itself up!
This removes the i915->gt.cleanup vfunc that has been annoying the
casual reader and myself for the last several years, and helps keep a
future patch to add more cleanup tidy.
v2: Assert that engine->destroy is set after the backend starts
alloc
Quoting Tvrtko Ursulin (2019-04-25 12:01:36)
>
> On 25/04/2019 10:19, Chris Wilson wrote:
> > Make the engine responsible for cleaning itself up!
>
> Why? (Just a hint to explain in the commit message.)
... so we can remove the vfunc stuck away inside the i915->gt that has
been annoying the read
== Series Details ==
Series: series starting with [01/45] drm/i915: Seal races between async GPU
cancellation, retirement and signaling
URL : https://patchwork.freedesktop.org/series/59933/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d3bdb17e90b7 drm/i915: Seal races between
Quoting Mika Kuoppala (2019-04-25 11:40:13)
> Chris Wilson writes:
> > + /* Now the semaphore is spinning, cancel it */
> > + cancel = gem_create(i915, 4096);
> > + cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
> > + *cs++ = MI_STORE_D
On 25/04/2019 10:19, Chris Wilson wrote:
Make the engine responsible for cleaning itself up!
Why? (Just a hint to explain in the commit message.)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 63 +
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Introduce struct intel_wakeref
URL : https://patchwork.freedesktop.org/series/59904/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5992_full -> Patchwork_12865_full
===
Op 26-02-2019 om 17:17 schreef Matt Roper:
> On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 21-02-2019 om 01:28 schreef Matt Roper:
>>> Some display controllers can be programmed to present non-black colors
>>> for pixels not covered by any plane (or pixels cove
On 25/04/2019 11:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-25 11:20:47)
On 25/04/2019 10:19, Chris Wilson wrote:
Having removed the urge to modify the engine_mask at runtime, we can
promote the num_engines from a runtime calculation to a static and push
it into the device_info t
Quoting Tvrtko Ursulin (2019-04-25 11:35:01)
>
> On 25/04/2019 10:19, Chris Wilson wrote:
> > Currently there is an underlying assumption that i915_request_unsubmit()
> > is synchronous wrt the GPU -- that is the request is no longer in flight
> > as we remove it. In the near future that may chang
Chris Wilson writes:
> Check that we can reorder batches around userspace sempahore waits by
semaphore
> injecting a semaphore that is only released by a later context.
>
> Signed-off-by: Chris Wilson
> ---
> tests/i915/gem_exec_schedule.c | 143 +
> 1 file cha
On 25/04/2019 10:19, Chris Wilson wrote:
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an in
Quoting Tvrtko Ursulin (2019-04-25 11:20:47)
>
> On 25/04/2019 10:19, Chris Wilson wrote:
> > Having removed the urge to modify the engine_mask at runtime, we can
> > promote the num_engines from a runtime calculation to a static and push
> > it into the device_info tables.
>
> What about fused o
On 25/04/2019 10:19, Chris Wilson wrote:
Having removed the urge to modify the engine_mask at runtime, we can
promote the num_engines from a runtime calculation to a static and push
it into the device_info tables.
What about fused off engines (intel_device_info_init_mmio)?
I don't see the pat
* Thomas Gleixner wrote:
> - if (unlikely(!ret))
> + if (unlikely(!ret)) {
> + if (!trace->nr_entries) {
> + /*
> + * If save_trace fails here, the printing might
> + * trigger a WARN but because of the !nr_entries
Replace the stack_trace_save*() functions with the new arch_stack_walk()
interfaces.
Signed-off-by: Thomas Gleixner
Cc: linux-a...@vger.kernel.org
---
arch/x86/Kconfig |1
arch/x86/kernel/stacktrace.c | 116 +++
2 files changed, 20 insert
1 - 100 of 190 matches
Mail list logo
