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 th
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 fo
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,
>
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 update
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 ins
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;
> > +
> > + mutex_lock(&i915->gt
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
> >
On Thu, 10 Jan 2019, Aditya Swarup wrote:
> CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
> configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
>
> v2: Jani suggested to keep the macros organized semantically i.e., by
> function, secondarily by port/pipe/transc
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 a
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
---
drivers/gpu/drm/i915/i915_drv.
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 a
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;
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, true)
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 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
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
-drivers/gpu
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)
__i915_gem_userptr_se
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. And
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 exce
== 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
---
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 wak
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 t
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 u
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 yeste
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 ins
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.
>
> Signed-off-by:
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 *__i915_mutex_lock_recursiv
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)
>
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 = __i915_gem_userptr_get_p
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 th
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 th
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
---
drivers/gpu/drm/i
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. And
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 ins
Quoting Tvrtko Ursulin (2019-01-15 12:37:43)
>
> On 15/01/2019 12:17, Chris Wilson wrote:
> > + if (!unlock) {
> > + unlock = &mn->mm->i915->drm.struct_mutex;
> > +
> > + switch (mutex_trylock_recursive(unlock)) {
> > + defaul
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 th
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: M
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
>
== 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 mark
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, that
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
== 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**
No
== 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
---
== 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
Summa
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 e
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 actuall
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 automatically
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
r
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 def
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'
> >> >
> >
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 subtes
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 configurati
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, p
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 for
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 wa
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 her
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 th
== 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 for
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 the
== 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
==
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 fb
== 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] drivers/gpu/drm/i915/i9
== 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
---
**SUCCE
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 seqno,
== 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
S
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
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;
+
+ mutex_
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
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 +++
lib/i
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 Maarten]
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 inse
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 = timelin
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 = igt_drm_format_t
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 e
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. Howev
== 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: WARNING
== 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 intel_encoder->compute_config()
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
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, that
== 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
Summa
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 ope
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 +
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
---
drivers/gpu/drm/i915/i915_g
== 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
---
== 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 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 bitfie
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,
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 f
== 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
>
== 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
Summary
1 - 100 of 102 matches
Mail list logo
