Quoting Tvrtko Ursulin (2019-01-15 10:19:11)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > @@ -620,40 +682,24 @@ static int i915_gem_userptr_get_pages(struct
> > drm_i915_gem_object *obj)
> > return -EAGAIN;
> > }
> >
> > - pvec = NULL;
> > - pinned = 0;
Chris Wilson writes:
> drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
> 'wakeref' not described in 'i915_perf_stream'
>
> Reported-by: kbuild-...@01.org
> Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
On 15/01/2019 12:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY
== Series Details ==
Series: drm: Split out drm_probe_helper.h
URL : https://patchwork.freedesktop.org/series/55232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
43cc5973457c drm: Split out drm_probe_helper.h
-:606: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_drv.c is
== Series Details ==
Series: drm/i915: Only dump GPU state on set-wedged if interesting
URL : https://patchwork.freedesktop.org/series/55239/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424 -> Patchwork_11298
Summary
Quoting Ville Syrjälä (2019-01-15 13:43:41)
> On Mon, Jan 14, 2019 at 09:55:10AM +, Tvrtko Ursulin wrote:
> >
> > On 11/01/2019 19:46, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > To overcome display engine stride limits we'll want to remap the
> > > pages in the GTT. To that
Hi Daniel,
Thank you for the patch.
On Tuesday, 15 January 2019 12:41:37 EET Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-15 10:45:50)
>> Chris Wilson writes:
>>
>> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or
>> > member 'wakeref' not described in 'i915_perf_stream'
>> >
>> > Reported-by: kbuild-...@01.org
>> > Fixes: 6619c0075f78
Hi all,
I would like to have some Acked-by's from you, the distro media
folks Cc'd here, to document your intent to start using Intel's
new media driver[1]. So if you recognize yourself (or are otherwise
interested), please read on.
TL;DR Distro folks, please give your Acked-by on patch [5/6]
I
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
From: Tvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.
v2:
* Split image setup a bit differently. (Chris Wilson)
v3:
* Update context image after reset as well - otherwise the application
of pinned
Quoting Mika Kuoppala (2019-01-15 14:44:13)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-01-15 10:45:50)
> >> Chris Wilson writes:
> >>
> >> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or
> >> > member 'wakeref' not described in 'i915_perf_stream'
> >> >
>
On 15/01/2019 10:41, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-15 10:27:02)
On 14/01/2019 21:17, Chris Wilson wrote:
+ if (err)
+ goto err_unlock;
+
+ err = __i915_gem_userptr_get_pages_schedule(obj);
+ if (err == -EAGAIN)
As we may frequently mark the device as wedged to flush requests off it
during the normal course of events, quite often we have a large state
dump that is of no interest. Don't bother dumping it all if the engines
are all idle.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
== Series Details ==
Series: drm: Split out drm_probe_helper.h
URL : https://patchwork.freedesktop.org/series/55232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424 -> Patchwork_11297
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
URL : https://patchwork.freedesktop.org/series/55226/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5421_full -> Patchwork_11296_full
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context.
From: Tvrtko Ursulin
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
v2:
* Rename some helpers for clarity.
* Include
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu
Quoting Tvrtko Ursulin (2019-01-14 09:55:10)
>
> On 11/01/2019 19:46, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To overcome display engine stride limits we'll want to remap the
> > pages in the GTT. To that end we need a new gtt_view type which
> > is just like the "rotated" type
Quoting Tvrtko Ursulin (2019-01-15 10:52:52)
>
> On 15/01/2019 10:41, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-15 10:27:02)
> >>
> >> On 14/01/2019 21:17, Chris Wilson wrote:
> >>> + if (err)
> >>> + goto err_unlock;
> >>> +
> >>> + err =
On 15/01/2019 11:41, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers.
Chris Wilson writes:
> As we may frequently mark the device as wedged to flush requests off it
> during the normal course of events, quite often we have a large state
> dump that is of no interest. Don't bother dumping it all if the engines
> are all idle.
>
> Signed-off-by: Chris Wilson
> Cc:
On Mon, Jan 14, 2019 at 09:55:10AM +, Tvrtko Ursulin wrote:
>
> On 11/01/2019 19:46, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To overcome display engine stride limits we'll want to remap the
> > pages in the GTT. To that end we need a new gtt_view type which
> > is just like the
Quoting Mika Kuoppala (2019-01-15 10:45:50)
> Chris Wilson writes:
>
> > drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
> > 'wakeref' not described in 'i915_perf_stream'
> >
> > Reported-by: kbuild-...@01.org
> > Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm
On 15/01/2019 10:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-14 09:55:10)
On 11/01/2019 19:46, Ville Syrjala wrote:
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like
Hi,
On 15-01-19 10:56, Daniel Vetter wrote:
On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
Hi,
On 27-12-18 15:42, Jani Nikula wrote:
On Tue, 25 Dec 2018, Hans de Goede wrote:
Hi,
As mentioned in the "I messed up drm-intel-next-queued!" mail-thread
I made a big mistake
On Mon, Jan 14, 2019 at 05:29:31PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore,
On 15/01/2019 10:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-15 09:47:45)
On 14/01/2019 21:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows
Quoting Mika Kuoppala (2019-01-15 11:56:11)
> Chris Wilson writes:
>
> > Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
> > consistently if called concurrently.
>
> More is needed in here. The purpose is to make them wait in turns
> on top of mutex, instead of racing on
Quoting Tvrtko Ursulin (2019-01-15 12:37:43)
>
> On 15/01/2019 12:17, Chris Wilson wrote:
> > + if (!unlock) {
> > + unlock = >mm->i915->drm.struct_mutex;
> > +
> > + switch (mutex_trylock_recursive(unlock)) {
> > + default:
On 15/01/2019 10:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-15 10:19:11)
On 14/01/2019 21:17, Chris Wilson wrote:
@@ -620,40 +682,24 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
return -EAGAIN;
}
- pvec = NULL;
Quoting Tvrtko Ursulin (2019-01-15 10:27:02)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > + if (err)
> > + goto err_unlock;
> > +
> > + err = __i915_gem_userptr_get_pages_schedule(obj);
> > + if (err == -EAGAIN)
> > __i915_gem_userptr_set_active(obj,
On Wed, 09 Jan 2019, Manasi Navare wrote:
> On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote:
>> intel_dp->dsc_dpcd is defined as an array making the if check redundant.
>>
>
> Yes I agree, I guess when I added that if check it was anot an array to begin
> with and then forgot
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull
Quoting Mika Kuoppala (2019-01-15 12:50:50)
> Chris Wilson writes:
>
> > As we may frequently mark the device as wedged to flush requests off it
> > during the normal course of events, quite often we have a large state
> > dump that is of no interest. Don't bother dumping it all if the engines
>
On Fri, Dec 21, 2018 at 04:02:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915/ddi: Move DDI port detection to
> the corresponding helper (rev2)
> URL : https://patchwork.freedesktop.org/series/54341/
> State : success
Thanks for the review,
On Sat, Dec 01, 2018 at 12:31:45PM +0100, Hans de Goede wrote:
> There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
> pixel-formats which this commit addresses:
>
> 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
> lanes. This assumption is not valid
On 14/01/2019 21:17, Chris Wilson wrote:
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it
drivers/gpu/drm/i915/i915_drv.h:1375: warning: Function parameter or member
'wakeref' not described in 'i915_perf_stream'
Reported-by: kbuild-...@01.org
Fixes: 6619c0075f78 ("drm/i915/perf: Track the rpm wakeref")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
On Tue, 15 Jan 2019, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers.
Quoting Tvrtko Ursulin (2019-01-15 10:40:24)
>
> On 15/01/2019 10:30, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-15 10:19:11)
> >>
> >> On 14/01/2019 21:17, Chris Wilson wrote:
> >>> @@ -620,40 +682,24 @@ static int i915_gem_userptr_get_pages(struct
> >>> drm_i915_gem_object *obj)
>
Chris Wilson writes:
> Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
> consistently if called concurrently.
More is needed in here. The purpose is to make them wait in turns
on top of mutex, instead of racing on the bit? Where is
the inconsistency tho.
>
>
Quoting Tvrtko Ursulin (2019-01-15 11:54:15)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > -static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> > *_mn,
> > - const struct mmu_notifier_range *range)
> > +static struct mutex
On Tue, 08 Jan 2019, Nathan Chancellor wrote:
> Hi all,
>
> Commit e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for
> DSC support/enable") causes a Clang warning:
>
> drivers/gpu/drm/i915/i915_debugfs.c:4961:17: warning: address of array
> 'intel_dp->dsc_dpcd' will always evaluate
== Series Details ==
Series: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
URL : https://patchwork.freedesktop.org/series/55226/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
== Series Details ==
Series: drm/i915/perf: Annotate i915_perf.wakeref for keneldoc
URL : https://patchwork.freedesktop.org/series/55226/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5421 -> Patchwork_11296
Summary
On 14/01/2019 21:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull
On Sat, Dec 01, 2018 at 12:31:46PM +0100, Hans de Goede wrote:
> The display engine has 2 dithering enable bits which both need to be set
> for dithering to happen, 1 in the PIPECONF register which is taken care of
> by i9xx_set_pipeconf() and a second bit at the encoder level.
>
> The dsi code
On 1/15/19 2:26 PM, Neil Armstrong wrote:
On 15/01/2019 11:41, Daniel Vetter wrote:
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal
== Series Details ==
Series: drm: Split out drm_probe_helper.h
URL : https://patchwork.freedesktop.org/series/55232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424_full -> Patchwork_11297_full
Summary
---
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote:
> On devices with a burst_mode_ratio which is not 100 (1:1), the pclk
> will have a different value then drm_display_mode.clock .
>
> On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock is 66100 and
> burst_mode_ratio is 130
== Series Details ==
Series: drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start (rev4)
URL : https://patchwork.freedesktop.org/series/51362/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1f795fb6dfe drm/i915/userptr: Avoid struct_mutex recursion
== Series Details ==
Series: drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start (rev4)
URL : https://patchwork.freedesktop.org/series/51362/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5427 -> Patchwork_11299
Quoting Chris Wilson (2019-01-15 09:14:17)
> Quoting John Harrison (2019-01-15 00:55:39)
> > On 1/7/2019 03:55, Chris Wilson wrote:
> > > Supplement the per-engine HWSP with a per-timeline HWSP. That is a
> > > per-request pointer through which we can check a local seqno,
> > > abstracting away
== Series Details ==
Series: Add uAPI to support ICL VME hardware for new media-driver
URL : https://patchwork.freedesktop.org/series/55249/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M]
== Series Details ==
Series: drm/i915: Only dump GPU state on set-wedged if interesting
URL : https://patchwork.freedesktop.org/series/55239/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5424_full -> Patchwork_11298_full
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
[rebased and addressed comments by
We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.
Although this is a rebase of v4 with all the comments addressed, I'm not
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
[rebased and updated do_writeback_test() function to address feedback]
Signed-off-by:
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 124 ++
1 file changed, 124
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 100 +++---
lib/igt_kms.h | 5 +++
2 files changed, 67 insertions(+), 38
From: Brian Starkey
Add support in igt_kms for writeback connectors, with the ability
to attach framebuffers.
Signed-off-by: Brian Starkey
[rebased and updated to the latest igt style]
Signed-off-by: Liviu Dudau
---
lib/igt_kms.c | 57 +++
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore,
On 1/15/2019 01:50, Chris Wilson wrote:
Quoting John Harrison (2019-01-15 00:56:13)
On 1/7/2019 03:55, Chris Wilson wrote:
+static int alloc_hwsp(struct i915_timeline *timeline)
+{
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_vma *vma;
+ int offset;
+
+
== Series Details ==
Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
URL : https://patchwork.freedesktop.org/series/55203/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Pass down rc in
== Series Details ==
Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
URL : https://patchwork.freedesktop.org/series/55203/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1238102f7caa drm/i915: Pass down rc in intel_encoder->compute_config()
-:26:
Quoting John Harrison (2019-01-15 19:57:19)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > Previously we only accommodated having a vma pinned by a small number of
> > users, with the maximum being pinned for use by the display engine. As
> > such, we used a small bitfield only large enough to allow
== Series Details ==
Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
URL : https://patchwork.freedesktop.org/series/55203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5429 -> Patchwork_11301
On Tue, Jan 15, 2019 at 12:52:29PM +0200, Jani Nikula wrote:
> On Wed, 09 Jan 2019, Manasi Navare wrote:
> > On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote:
> >> intel_dp->dsc_dpcd is defined as an array making the if check redundant.
> >>
> >
> > Yes I agree, I guess when I
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
Quoting Liviu Dudau (2019-01-15 17:47:44)
> +int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc)
> +{
> +#define FNV1a_OFFSET_BIAS 2166136261
> +#define FNV1a_PRIME 16777619
> + uint32_t hash;
> + void *map;
> + char *ptr, *line = NULL;
> + int x, y, cpp =
On 1/7/2019 03:55, Chris Wilson wrote:
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock.
On 1/15/2019 07:40, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-15 09:14:17)
Quoting John Harrison (2019-01-15 00:55:39)
On 1/7/2019 03:55, Chris Wilson wrote:
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local
Quoting John Harrison (2019-01-15 18:17:21)
> On 1/15/2019 01:50, Chris Wilson wrote:
> > Quoting John Harrison (2019-01-15 00:56:13)
> >> On 1/7/2019 03:55, Chris Wilson wrote:
> >>> +static int alloc_hwsp(struct i915_timeline *timeline)
> >>> +{
> >>> + struct drm_i915_private *i915 =
Move the debug pretty printer into a standalone routine prior to
extending it in upcoming feature work.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 55 ++--
drivers/gpu/drm/i915/intel_lrc.c | 58
== Series Details ==
Series: drm/i915: Move intel_execlists_show_requests() aside
URL : https://patchwork.freedesktop.org/series/55265/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5430 -> Patchwork_11302
Summary
---
We multiply the memfd 64k to create a 2G arena which we then attempt to
write into after marking read-only. Howver, when it comes to unlock the
arena after the test, performance tanks as the kernel tries to resolve
the 64k repeated mappings onto the same set of pages. (Must not be a
very common
mutex_lock_killable() returns -EINTR on failure, not the anticipate bool
return like trylock. (Oh no, not again.)
Fixes: 484d9a844d0d ("drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
== Series Details ==
Series: drm/i915/userptr: Fix error handling of mutex_lock_killable()
URL : https://patchwork.freedesktop.org/series/55267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5430 -> Patchwork_11303
Summary
On Tue, Jan 08, 2019 at 12:32:05PM -0800, Kenneth Graunke wrote:
> On Tuesday, January 8, 2019 7:53:05 AM PST Joonas Lahtinen wrote:
> > + Ken/Jason for Mesa
> > Quoting Matt Roper (2019-01-07 21:19:31)
> > > On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > > > On Mon, Jan 07,
== Series Details ==
Series: drm/i915: Pass down rc in intel_encoder->compute_config() (rev2)
URL : https://patchwork.freedesktop.org/series/55203/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5429_full -> Patchwork_11301_full
On Tue, Jan 15, 2019 at 5:41 AM Daniel Vetter wrote:
>
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
between commits:
e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for DSC
support/enable")
f6bff60e927b ("drm/i915/icl: Fix HPD handling
On 1/15/2019 12:17, Chris Wilson wrote:
Quoting John Harrison (2019-01-15 19:57:19)
On 1/7/2019 03:55, Chris Wilson wrote:
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small
== Series Details ==
Series: drm/i915/userptr: Fix error handling of mutex_lock_killable()
URL : https://patchwork.freedesktop.org/series/55267/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5430_full -> Patchwork_11303_full
== Series Details ==
Series: drm/i915: Move intel_execlists_show_requests() aside
URL : https://patchwork.freedesktop.org/series/55265/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5430_full -> Patchwork_11302_full
On 14/01/2019 21:17, Chris Wilson wrote:
On Braswell, under heavy stress, if we update the GGTT while
simultaneously accessing another region inside the GTT, we are returned
the wrong values. To prevent this we stop the machine to update the GGTT
entries so that no memory traffic can occur at
Chris Wilson writes:
> Th heavy variant of gem_ctx_switch does little more than provide an
> alternate timing for the basic gem_ctx_switch; the timing only effects
> the HW and does not stress the driver any differently. As such,
> including gem_ctx_switch/heavy provides no more basic coverage
Quoting John Harrison (2019-01-15 00:55:39)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > Supplement the per-engine HWSP with a per-timeline HWSP. That is a
> > per-request pointer through which we can check a local seqno,
> > abstracting away the presumption of a global seqno. In this first step,
Hi Daniel, Dave,
Here is the drm-misc-next PR for this week.
Thanks!
Maxime
drm-misc-next-2019-01-15:
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the
On Tue, 15 Jan 2019, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the
Quoting Tvrtko Ursulin (2019-01-15 09:04:47)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > On Braswell, under heavy stress, if we update the GGTT while
> > simultaneously accessing another region inside the GTT, we are returned
> > the wrong values. To prevent this we stop the machine to
On 14/01/2019 21:17, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY
Quoting John Harrison (2019-01-15 00:56:13)
> On 1/7/2019 03:55, Chris Wilson wrote:
> > +static int alloc_hwsp(struct i915_timeline *timeline)
> > +{
> > + struct drm_i915_private *i915 = timeline->i915;
> > + struct i915_vma *vma;
> > + int offset;
> > +
> > +
On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
> Hi,
>
> On 27-12-18 15:42, Jani Nikula wrote:
> > On Tue, 25 Dec 2018, Hans de Goede wrote:
> > > Hi,
> > >
> > > As mentioned in the "I messed up drm-intel-next-queued!" mail-thread
> > > I made a big mistake yesterday:
> > >
>
Quoting Tvrtko Ursulin (2019-01-15 09:47:45)
>
> On 14/01/2019 21:17, Chris Wilson wrote:
> > Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
> > notifiers") we have been able to report failure from
> > mmu_invalidate_range_start which allows us to use a trylock on the
> >
1 - 100 of 102 matches
Mail list logo
