== Series Details ==
Series: series starting with [v2,1/4] drm/i915: Also check view->type for a
normal GGTT view
URL : https://patchwork.freedesktop.org/series/38593/
State : success
== Summary ==
Series 38593v1 series starting with [v2,1/4] drm/i915: Also check view->type
for a normal GGTT
Quoting Chris Wilson (2018-02-20 10:45:16)
> A new context assumes that all of its registers are in the default state
> when it is created. What may happen is that a register written by one
> context may leak into the second, causing mass confusion.
>
> v2: Extend back to Sandybridge (etc)
> v3: C
Quoting Chris Wilson (2018-02-20 10:45:17)
> Ensure that we always use every context at least once before we start
> running the stress-test.
>
> Signed-off-by: Chris Wilson
> ---
> tests/gem_ctx_switch.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/tests/gem_ctx_switch.c b/t
== Series Details ==
Series: series starting with [v2,1/4] drm/i915: Also check view->type for a
normal GGTT view
URL : https://patchwork.freedesktop.org/series/38593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4a4061e50613 drm/i915: Also check view->type for a normal GGTT
PSR may not exit instantaneously, so while asserting that PSR is
disabled after an action, we may have to wait a short while. Currently
that wait is waiting for PSR to enabled and expecting to timeout; this
fails when we start the assertion with PSR already enabled. Fix the wait
to wait until PSR i
On Tue, Feb 20, 2018 at 05:42:59PM +0800, Mustamin B Mustaffa wrote:
> Currently, BXT_PP is hardcoded with value '0'.
> It practically disabled eDP backlight on MRB (BXT) platform.
>
> This patch will tell which BXT_PP registers (there are two set of
> PP_CONTROL in the spec) to be used as defined
Quoting Christian König (2018-02-20 09:45:54)
> Am 20.02.2018 um 10:37 schrieb Chris Wilson:
> > When we descend the tree to find our slot, if we step to the right, we
> > are no longer the leftmost node.
> >
> > Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
> > Signed-off-by: C
On Tue, Feb 20, 2018 at 02:20:17PM +0100, Daniel Vetter wrote:
> Noticed while reading some unrelated patches. Unfortunately Imre's
> patch to add our early/late hooks predated the device_link
> infrastructure by 2 years.
>
> Cc: Imre Deak
> Cc: Takashi Iwai
> Signed-off-by: Daniel Vetter
Yep,
== Series Details ==
Series: drm/i915: Make global seqno known in i915_gem_request_execute tracepoint
URL : https://patchwork.freedesktop.org/series/38578/
State : success
== Summary ==
Test gem_softpin:
Subgroup noreloc-s3:
pass -> SKIP (shard-snb) fdo#1033
== Series Details ==
Series: drm/i915: Enable VBT based BL control for DP (v3) (rev4)
URL : https://patchwork.freedesktop.org/series/38559/
State : failure
== Summary ==
Test gem_softpin:
Subgroup noreloc-s3:
pass -> SKIP (shard-snb) fdo#103375 +1
Test gem_e
== Series Details ==
Series: drm/mm: Fix caching of leftmost node in the interval tree (rev2)
URL : https://patchwork.freedesktop.org/series/38351/
State : success
== Summary ==
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip -> PASS (shard-snb) f
Quoting Ville Syrjälä (2018-02-20 13:59:53)
> On Tue, Feb 20, 2018 at 01:42:08PM +, Chris Wilson wrote:
> > Rather than trusting the cached value of plane_state->vma->fence to
> > imply whether the plane_state itself holds a reference on the
> > framebuffer's fence, use the information provided
On Tue, Feb 20, 2018 at 01:42:08PM +, Chris Wilson wrote:
> Rather than trusting the cached value of plane_state->vma->fence to
> imply whether the plane_state itself holds a reference on the
> framebuffer's fence, use the information provided in the
> plane_state->flags (PLANE_HAS_FENCE). Note
On Tue, Feb 20, 2018 at 01:42:07PM +, Chris Wilson wrote:
> Use the information about the fence state from the time of pinning to
> determine if the fbdev writes are going through a fence. This avoids any
> confusion in cases where the fence may appear or disappear unconnected
> to the use by f
Convert the busy pwm from using a single calibration pass with a fixed
target into a self-correcting pwm that tries to adjust how long to sleep
on each pwm in order to converge at the target busy %%.
Being self-correcting, it should fare better against the more variable
systems CI presents.
v2: B
Quoting Chris Wilson (2018-02-20 13:25:21)
> Convert the busy pwm from using a single calibration pass with a fixed
> target into a self-correcting pwm that tries to adjust how long to sleep
> on each pwm in order to converge at the target busy %%.
>
> Being self-correcting, it should fare better
On Tue, Feb 20, 2018 at 12:26:59PM +0100, Daniel Vetter wrote:
> On Wed, Feb 14, 2018 at 09:23:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties,
> > and the i915 implementation I did on top. I tossed in a few cor
Use the information about the fence state from the time of pinning to
determine if the fbdev writes are going through a fence. This avoids any
confusion in cases where the fence may appear or disappear unconnected
to the use by fbdev.
Suggested-by: Ville Syrjälä
Signed-off-by: Chris Wilson
Cc: V
Rather than trusting the cached value of plane_state->vma->fence to
imply whether the plane_state itself holds a reference on the
framebuffer's fence, use the information provided in the
plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC
is entirely bounded by the plane_state
Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruc
We cannot simply use !view as shorthand for all normal GGTT views as a
few callers will always populate a i915_ggtt_view struct and set the
type to NORMAL instead. So check for (!view || view->type == NORMAL)
inside i915_gem_object_ggtt_pin().
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Revi
== Series Details ==
Series: drm/todo: i915 could use device_link_add
URL : https://patchwork.freedesktop.org/series/38588/
State : success
== Summary ==
Series 38588v1 drm/todo: i915 could use device_link_add
https://patchwork.freedesktop.org/api/1.0/series/38588/revisions/1/mbox/
Test gem_m
Convert the busy pwm from using a single calibration pass with a fixed
target into a self-correcting pwm that tries to adjust how long to sleep
on each pwm in order to converge at the target busy %%.
Being self-correcting, it should fare better against the more variable
systems CI presents.
Bugzi
== Series Details ==
Series: series starting with [1/4] drm/i915: Also check view->type for a normal
GGTT view
URL : https://patchwork.freedesktop.org/series/38585/
State : warning
== Summary ==
Series 38585v1 series starting with [1/4] drm/i915: Also check view->type for a
normal GGTT view
Noticed while reading some unrelated patches. Unfortunately Imre's
patch to add our early/late hooks predated the device_link
infrastructure by 2 years.
Cc: Imre Deak
Cc: Takashi Iwai
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 7 +++
1 file changed, 7 insertions(+)
diff
== Series Details ==
Series: series starting with [1/4] drm/i915: Also check view->type for a normal
GGTT view
URL : https://patchwork.freedesktop.org/series/38585/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
284097cf5955 drm/i915: Also check view->type for a normal GGTT vie
Rather than trusting the cached value of plane_state->vma->fence to
imply whether the plane_state itself holds a reference on the
framebuffer's fence, use the information provided in the
plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC
is entirely bounded by the plane_state
Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruc
Use the information about the fence state from the time of pinning to
determine if the fbdev writes are going through a fence. This avoids any
confusion in cases where the fence may appear or disappear unconnected
to the use by fbdev.
Suggested-by: Ville Syrjälä
Signed-off-by: Chris Wilson
Cc: V
We cannot simply use !view as shorthand for all normal GGTT views as a
few callers will always populate a i915_ggtt_view struct and set the
type to NORMAL instead. So check for (!view || view->type == NORMAL)
inside i915_gem_object_ggtt_pin().
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Revi
Quoting Daniel Vetter (2018-02-20 12:17:18)
> On Thu, Feb 15, 2018 at 09:21:47AM +, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-02-11 18:54:33)
> > > Signed-off-by: Chris Wilson
> >
> > Poke, CI is still tripping over this...
>
> Can you give a bit more context about what's going on a
On Thu, Feb 15, 2018 at 09:21:47AM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-02-11 18:54:33)
> > Signed-off-by: Chris Wilson
>
> Poke, CI is still tripping over this...
Can you give a bit more context about what's going on and how this
happens? Bugzilla or whatever ... I'm confused
Quoting Patchwork (2018-02-20 12:03:36)
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Also check view->type for a
> normal GGTT view
> URL : https://patchwork.freedesktop.org/series/38579/
> State : warning
>
> == Summary ==
>
> Series 38579v1 series starting with [1
== Series Details ==
Series: series starting with [1/2] drm/i915: Also check view->type for a normal
GGTT view
URL : https://patchwork.freedesktop.org/series/38579/
State : warning
== Summary ==
Series 38579v1 series starting with [1/2] drm/i915: Also check view->type for a
normal GGTT view
On Tue, Feb 20, 2018 at 10:50:10AM +, Chris Wilson wrote:
> We cannot simply use !view as shorthand for all normal GGTT views as a
> few callers will always populate a i915_ggtt_view struct and set the
> type to NORMAL instead. So check for (!view || view->type == NORMAL)
> inside i915_gem_obje
== Series Details ==
Series: series starting with [1/2] drm/i915: Also check view->type for a normal
GGTT view
URL : https://patchwork.freedesktop.org/series/38579/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c5a4e635c47b drm/i915: Also check view->type for a normal GGTT vie
Quoting Ville Syrjälä (2018-02-20 11:39:13)
> On Tue, Feb 20, 2018 at 10:50:11AM +, Chris Wilson wrote:
> > @@ -490,6 +491,8 @@ struct intel_atomic_state {
> > struct intel_plane_state {
> > struct drm_plane_state base;
> > struct i915_vma *vma;
> > + unsigned long flags;
>
>
On Tue, Feb 20, 2018 at 10:50:11AM +, Chris Wilson wrote:
> Currently we make the unilateral decision inside
> i915_gem_object_pin_to_display() where the VMA should resided (inside
> the fence and mappable region or above?). This is not our decision to
> make as it impacts on how the display en
On Tue, 20 Feb 2018, Mustamin B Mustaffa wrote:
> In GVT guest, when port A is DP, i915 will force it as an EDP panel,
> which
> will cause DP-1 not working in GVT guest.
> This patch fixed this issue by check intel_vgpu_active() in
> intel_ddi_compute_config().
Just repeating Ville's question fr
On Wed, Feb 14, 2018 at 09:23:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Here's a refresh of Jyri's COLOR_ENCODING and COLOR_RANGE properties,
> and the i915 implementation I did on top. I tossed in a few core
> updates as well: plane state dump, and the BT.2020 constant luminance
On Mon, Feb 19, 2018 at 10:28:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Include color_enconding and color_range in the plane state dump.
>
> v2: Add kerneldoc (danvet)
>
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Daniel Stone
> Cc: Russell King - ARM Linux
> Cc: Ilia Mi
On Mon, Feb 19, 2018 at 10:28:23PM +0200, Ville Syrjala wrote:
> From: Jyri Sarha
>
> Add a standard optional properties to support different non RGB color
> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
Quoting Tvrtko Ursulin (2018-02-20 11:14:38)
>
> On 20/02/2018 10:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-02-20 10:47:42)
> >> From: Tvrtko Ursulin
> >>
> >> Commit fe49789fab97 ("drm/i915: Deconstruct execute fence") re-arranged
> >> the code and moved the i915_gem_request_execu
== Series Details ==
Series: drm/i915: Make global seqno known in i915_gem_request_execute tracepoint
URL : https://patchwork.freedesktop.org/series/38578/
State : success
== Summary ==
Series 38578v1 drm/i915: Make global seqno known in i915_gem_request_execute
tracepoint
https://patchwork.f
On 20/02/18 11:05, Tvrtko Ursulin wrote:
On 15/02/2018 12:02, Lionel Landwerlin wrote:
With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
G
Quoting Chris Wilson (2018-02-20 10:45:14)
> One weird issue we see in bug 104676 is that the hangs are too fast on
> HSW! So force the use of the slow spinners that do not try to trigger
> a hang by injecting random bytes into the batch.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=
On 20/02/2018 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-02-20 10:47:42)
From: Tvrtko Ursulin
Commit fe49789fab97 ("drm/i915: Deconstruct execute fence") re-arranged
the code and moved the i915_gem_request_execute tracepoint to before the
global seqno is assigned to the request.
On 15/02/2018 12:02, Lionel Landwerlin wrote:
With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate n
Quoting Joonas Lahtinen (2018-02-20 10:57:44)
> Quoting Chris Wilson (2018-02-20 10:45:12)
> > @@ -398,7 +399,7 @@ static void preempt(int fd, unsigned ring, unsigned
> > flags)
> > igt_assert(gem_bo_busy(fd, spin[0]->handle));
> > }
> >
> > - for (int n = 0; n < 16
== Series Details ==
Series: drm/i915: Enable VBT based BL control for DP (v3) (rev4)
URL : https://patchwork.freedesktop.org/series/38559/
State : success
== Summary ==
Series 38559v4 drm/i915: Enable VBT based BL control for DP (v3)
https://patchwork.freedesktop.org/api/1.0/series/38559/revi
On 15/02/2018 12:02, Lionel Landwerlin wrote:
There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices
Quoting Chris Wilson (2018-02-20 10:45:12)
> @@ -398,7 +399,7 @@ static void preempt(int fd, unsigned ring, unsigned flags)
> igt_assert(gem_bo_busy(fd, spin[0]->handle));
> }
>
> - for (int n = 0; n < 16; n++)
> + for (int n = 0; n < MAX_ELSP_QLEN; n++)
>
Quoting Tvrtko Ursulin (2018-02-20 10:47:42)
> From: Tvrtko Ursulin
>
> Commit fe49789fab97 ("drm/i915: Deconstruct execute fence") re-arranged
> the code and moved the i915_gem_request_execute tracepoint to before the
> global seqno is assigned to the request.
>
> We need to move the tracepoint
Quoting Chris Wilson (2018-02-20 10:45:11)
> icl offers a much reduced context space, and in its simplest setup we
> cannot allocate one context per priority level, so trim the number and
> reuse the same context for multiple priority requests.
>
> v2: Bump the MAX to 1024 (still lower than the ~4
Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruc
We cannot simply use !view as shorthand for all normal GGTT views as a
few callers will always populate a i915_ggtt_view struct and set the
type to NORMAL instead. So check for (!view || view->type == NORMAL)
inside i915_gem_object_ggtt_pin().
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
From: Tvrtko Ursulin
Commit fe49789fab97 ("drm/i915: Deconstruct execute fence") re-arranged
the code and moved the i915_gem_request_execute tracepoint to before the
global seqno is assigned to the request.
We need to move the tracepoint a bit later so this information is once
again available.
== Series Details ==
Series: drm/i915: Enable VBT based BL control for DP (v3) (rev4)
URL : https://patchwork.freedesktop.org/series/38559/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e4ce0242c53b drm/i915: Enable VBT based BL control for DP
-:35: WARNING: line over 80 charac
== Series Details ==
Series: drm/mm: Fix caching of leftmost node in the interval tree (rev2)
URL : https://patchwork.freedesktop.org/series/38351/
State : success
== Summary ==
Series 38351v2 drm/mm: Fix caching of leftmost node in the interval tree
https://patchwork.freedesktop.org/api/1.0/s
Quoting Chris Wilson (2018-02-19 18:10:03)
> Convert from using constant loops of indeterminate loads over to using a
> duration based with precise dummyloads, we are able to do more cycles in
> less time by limiting the amount of BUSY_LOAD required to exercise the
> test.
>
> Signed-off-by: Chris
Quoting Chris Wilson (2018-02-19 10:57:28)
> When we insert a node into a hole inside the interval tree, we need to
> climb the layers above us to update the cached interval. When doing so,
> we know that the initial node exists as it is our starting hole.
>
> add/remove: 0/0 grow/shrink: 0/1 up/d
Am 20.02.2018 um 10:37 schrieb Chris Wilson:
When we descend the tree to find our slot, if we step to the right, we
are no longer the leftmost node.
Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
Signed-off-by: Chris Wilson
Cc: Davidlohr Bueso
Cc: Jérôme Glisse
Cc: Christia
On Tue, 20 Feb 2018, Chris Wilson wrote:
> Quoting Mustaffa, Mustamin B (2018-02-20 08:44:45)
>> Hi Chris,
>>
>> Would you rather for me to use following line instead?
>>
>> + int backlight_controller =
>> intel_dp->attached_connector->panel.backlight.controller;
>
> I think so, Jani wo
Currently, BXT_PP is hardcoded with value '0'.
It practically disabled eDP backlight on MRB (BXT) platform.
This patch will tell which BXT_PP registers (there are two set of
PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing
table) and this will enabled eDP backlight controlle
When we descend the tree to find our slot, if we step to the right, we
are no longer the leftmost node.
Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
Signed-off-by: Chris Wilson
Cc: Davidlohr Bueso
Cc: Jérôme Glisse
Cc: Christian König
Reviewed-by: Joonas Lahtinen
---
dri
Quoting Chris Wilson (2018-02-19 10:57:27)
> When we descend the tree to find our slot, if we step to the right, we
> are no longer the leftmost node.
>
> Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
> Signed-off-by: Chris Wilson
> Cc: Davidlohr Bueso
> Cc: Jérôme Glisse
>
Quoting Mustaffa, Mustamin B (2018-02-20 08:44:45)
> Hi Chris,
>
> Would you rather for me to use following line instead?
>
> + int backlight_controller =
> intel_dp->attached_connector->panel.backlight.controller;
I think so, Jani would be best to answer the question about how
vbt/pane
Quoting Patchwork (2018-02-20 01:40:51)
> == Series Details ==
>
> Series: drm/i915: Track number of pending freed objects (rev2)
> URL : https://patchwork.freedesktop.org/series/38537/
> State : warning
>
> == Summary ==
>
> Test gem_eio:
> Subgroup in-flight:
> pass
Quoting Daniel Vetter (2018-02-19 15:52:34)
> On Mon, Feb 19, 2018 at 02:43:59PM +, Chris Wilson wrote:
> > Quoting Joonas Lahtinen (2018-02-19 14:40:32)
> > > Quoting Chris Wilson (2018-02-19 13:35:43)
> > > > +++ b/drivers/gpu/drm/drm_mm.c
> > > > @@ -836,9 +836,24 @@ struct drm_mm_node *drm_
Quoting Chris Wilson (2018-02-19 22:12:28)
> When the asserts were added for the acceptable error codes for
> SET_CACHING ioctl, foresight was not given to the possibility that the
> device may not handle the caching mode and return -ENODEV. Remove the
> error code assertion from the library, that
Quoting Chris Wilson (2018-02-19 22:12:27)
> syncobj_basic.c: In function ‘__real_main225’:
> syncobj_basic.c:202:26: warning: ‘fd’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> syncobj_basic.c:227:6: note: ‘fd’ was declared here
> syncobj_wait.c: In function ‘test_wait_co
Quoting Chris Wilson (2018-02-19 22:12:26)
> gem_exec_flush.c: In function ‘batch’:
> gem_exec_flush.c:443:15: warning: ‘ptr’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
_
Quoting Chris Wilson (2018-02-19 22:12:25)
> igt_debugfs.c: In function 'igt_assert_crc_equal':
> igt_debugfs.c:353:3: warning: 'index' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> igt_debugfs.c: In function 'igt_check_crc_equal':
> igt_debugfs.c:375:3: warning: 'index' m
Quoting Chris Wilson (2018-02-20 00:18:07)
> When using igt_debugfs_*() inside a tight loop, the overhead of calling
> xstat64 (from is_mountpoint()) creeps up in the profiles. Eliminate it
> by caching the resultant path for finding/mounting debugfs.
>
> Signed-off-by: Chris Wilson
Reviewed-by:
Quoting Chris Wilson (2018-02-20 00:18:06)
> Don't just wait for the batch to be completed, wait for the system to
> idle! Then wake it up and do it again.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mai
EXEC_OBJECT_CAPTURE extends the type of buffers we may read during error
capture. Previously we knew that we would only see batch buffers (which
limited the objects to being from gem_create()), but now we need to
check that any buffer the user can create can be read. The first
alternate buffer type
One weird issue we see in bug 104676 is that the hangs are too fast on
HSW! So force the use of the slow spinners that do not try to trigger
a hang by injecting random bytes into the batch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104676
Signed-off-by: Chris Wilson
---
lib/igt_gt.c
Build up a large stockpile of requests, ~500,000, and feed them into the
system at 20KHz whilst simultaneously triggering set-wedged in order to
try and race i915_gem_set_wedged() against the engine->submit_request()
callback.
Signed-off-by: Chris Wilson
---
tests/gem_eio.c | 196 +++
Execute the same batch on each engine and check that the composite fence
across all engines completes only after the batch is completed on every
engine.
Signed-off-by: Chris Wilson
---
tests/gem_exec_fence.c | 127 +
1 file changed, 127 insertions(
Ensure that we always use every context at least once before we start
running the stress-test.
Signed-off-by: Chris Wilson
---
tests/gem_ctx_switch.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c
index 4db902b1..e0ab3d18 100644
--- a/t
gem_exec_flush.c: In function ‘batch’:
gem_exec_flush.c:443:15: warning: ‘ptr’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
Signed-off-by: Chris Wilson
---
tests/gem_exec_flush.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/gem_exec_flush.c b/tests/gem_ex
s/16/MAX_ELSP_QLEN/ as appropriate
Signed-off-by: Chris Wilson
---
tests/gem_exec_schedule.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 1fc7c697..21102591 100644
--- a/tests/gem_exec_schedu
Just a small variant to apply a continuous context-switch load to all
engines.
---
tests/gem_ctx_switch.c | 76 ++
1 file changed, 76 insertions(+)
diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c
index e0ab3d18..9b5560c0 100644
--- a/te
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.
v2: Extend back to Sandybridge (etc)
v3: Check context preserves registers across suspend/hiberna
syncobj_basic.c: In function ‘__real_main225’:
syncobj_basic.c:202:26: warning: ‘fd’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
syncobj_basic.c:227:6: note: ‘fd’ was declared here
syncobj_wait.c: In function ‘test_wait_complex’:
syncobj_wait.c:702:3: warning: ‘first_signale
icl offers a much reduced context space, and in its simplest setup we
cannot allocate one context per priority level, so trim the number and
reuse the same context for multiple priority requests.
v2: Bump the MAX to 1024 (still lower than the ~4096 previously in use)
v3: Also limit NCTX to MAX_CON
igt_debugfs.c: In function 'igt_assert_crc_equal':
igt_debugfs.c:353:3: warning: 'index' may be used uninitialized in this
function [-Wmaybe-uninitialized]
igt_debugfs.c: In function 'igt_check_crc_equal':
igt_debugfs.c:375:3: warning: 'index' may be used uninitialized in this
function [-Wmaybe-u
When using igt_debugfs_*() inside a tight loop, the overhead of calling
xstat64 (from is_mountpoint()) creeps up in the profiles. Eliminate it
by caching the resultant path for finding/mounting debugfs.
Signed-off-by: Chris Wilson
---
lib/igt_debugfs.c | 26 ++
1 file cha
When the asserts were added for the acceptable error codes for
SET_CACHING ioctl, foresight was not given to the possibility that the
device may not handle the caching mode and return -ENODEV. Remove the
error code assertion from the library, that is the job for the ABI
tests.
Signed-off-by: Chris
Convert from using constant loops of indeterminate loads over to using a
duration based with precise dummyloads, we are able to do more cycles in
less time by limiting the amount of BUSY_LOAD required to exercise the
test.
Signed-off-by: Chris Wilson
---
tests/gem_fenced_exec_thrash.c | 109
Don't just wait for the batch to be completed, wait for the system to
idle! Then wake it up and do it again.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index a
Hi Chris,
Would you rather for me to use following line instead?
+ int backlight_controller =
intel_dp->attached_connector->panel.backlight.controller;
Best regard
Mustamin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Tuesday, February 20, 2
Quoting Mustamin B Mustaffa (2018-02-20 06:52:49)
> Currently, BXT_PP is hardcoded with value '0'.
> It practically disabled eDP backlight on MRB (BXT) platform.
>
> This patch will tell which BXT_PP registers (there are two set of
> PP_CONTROL in the spec) to be used as defined in VBT (Video Bios
== Series Details ==
Series: drm/i915: Enable VBT based BL control for DP (v3) (rev3)
URL : https://patchwork.freedesktop.org/series/38559/
State : success
== Summary ==
Test perf:
Subgroup buffer-fill:
fail -> PASS (shard-apl) fdo#103755
Subgroup oa
101 - 194 of 194 matches
Mail list logo
