On Wed, 16 May 2018, Lucas De Marchi wrote:
> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
>
> This fails on a Dell XPS13 9350 machine giving me just a black screen.
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane
On Wed, 16 May 2018, Dhinakaran Pandiyan wrote:
> On Wed, 2018-05-16 at 11:01 +0300, Jani Nikula wrote:
>> This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e.
>>
>> Per the report, no matter what display mode you select with xrandr,
>> the
>> i915 driver will always select the alternate
Ping..
On Tue, 2018-05-15 at 16:59 +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content type setting property to drm_connector(part 1)
> and enabled transmitting it with HDMI AVI infoframes
> for i915(part 2).
>
> Stanislav Lisovskiy (2):
> drm: content-type property for HDMI c
On Wed, 16 May 2018, Manasi Navare wrote:
> This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
> Do not do link training fallback or prune modes on EDP") that causes
> a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350)
> where first link training fails and
On Thu, 17 May 2018, Jani Nikula wrote:
> On Wed, 16 May 2018, Dhinakaran Pandiyan
> wrote:
>> On Wed, 2018-05-16 at 11:01 +0300, Jani Nikula wrote:
>>> This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e.
>>>
>>> Per the report, no matter what display mode you select with xrandr,
>>>
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
gen8_cs_irq_handler 512 428 -84
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 4 +++-
drivers/gpu/drm/i915/i
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4
Move the knowledge about resetting the current context tracking on the
engine from inside i915_gem_context.c into intel_engine_cs.c
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
drivers/gpu/drm/i915/intel_engine_cs.c | 23
We want to be able to reset the GPU from inside a timer callback
(hardirq context). One step requires us to copy the default context
state over to the guilty context, which means we need to plan in advance
to have that object accessible from within an atomic context. The atomic
context prevents us
To be useful later, enable intel_engine_dump() to be called from irq
context (i.e. using saving and restoring irq start rather than assuming
we enter with irqs enabled).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 11 +++
1 file changed, 7 insertions(+), 4 de
The HWACK bit more generically solves the problem of resubmitting ESLP
while the hardware is still processing the current ELSP write. We no
longer need to check port[0].count itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 2 --
1 file changed, 2 deletions(-)
diff --g
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 inserti
As we now only use the cached HWSP access to read the CSB buffer and no
longer use any forcewaked mmio, processing the CSB is fast and possible
to do so directly from inside the CS interrupt handler.
We have to rearrange the irq handler slightly as we wish to preserve the
single threaded access to
In the next patch, we want to store the intel_context pointer inside
i915_request, as it is frequently access via a convoluted dance when
submitting the request to hw. Having two context pointers inside
i915_request leads to confusion so first rename the existing
i915_gem_context pointer to i915_re
As we are splitting processing the CSB events from submitting the ELSP,
we also need to duplicate the check that we hold a device wakeref for our
hardware access to the disjoint locations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 26 --
1 file ch
In the next patch, we will begin processing the CSB from inside the
interrupt handler. This means that updating the execlists->port[] will
no longer be locked by the tasklet but by the engine->timeline.lock
instead. Pull dequeue and submit under the same lock for protection.
(An alternative, future
As all backends implement the same pin_count mechanism and do a
dec-and-test as their first step, pull that into the common
intel_context_unpin(). This also pulls into the caller, eliminating the
indirect call in the usual steady state case. The intel_context_pin()
side is a little more complicated
Having abandoned the split approach of acking then handling the GT irqs
(sacrificed to use the interrupt handler to guaranteed exclusive access
to the irq data), pull the two routines into one to let the compiler
eliminate the redundant storage.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i9
In the next patch, we will process the CSB events directly from the CS
interrupt handler, being called for each interrupt. Hence, we will no
longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
Signed-off-by: Chris Wilson
--
To ease the frequent and ugly pointer dance of
&request->gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.
v2: Set mo
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 27 +++
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on av
We can avoid the mmio read of the CSB pointers after reset based on the
knowledge that the HW always start writing at entry 0 in the CSB buffer.
We need to reset our CSB head tracking after GPU reset (and on
sanitization after resume) so that we are expecting to read from entry
0.
Signed-off-by: C
Hi Daniel,
First bad commit (maybe != root cause):
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 64b3f927aacc356dd742b3a83aead21fba7e56dd [6/9] lockdep: finer-grained
completion key for kthread
reproduce: make htmldocs
On Wed, 16 May 2018, Dhinakaran Pandiyan wrote:
> On Wed, 2018-05-16 at 11:08 +0300, Jani Nikula wrote:
>> I think the patch is now the way it should be. We should not change
>> our interpretation based on the value.
>
> Is it correct to infer, from your response, that VBT values are not
> always
== Series Details ==
Series: series starting with [01/19] drm/i915: Move request->ctx aside
URL : https://patchwork.freedesktop.org/series/43307/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
61b8422e1e2d drm/i915: Move request->ctx aside
2bb24771dc50 drm/i915: Move fiddling wi
== Series Details ==
Series: series starting with [01/19] drm/i915: Move request->ctx aside
URL : https://patchwork.freedesktop.org/series/43307/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Move request->ctx aside
Okay!
Commit: drm/i915: Move fiddling with engi
On Thu, 17 May 2018, "C, Ramalingam" wrote:
>> > >> +/**
>> > > Drop the extra *, unless you really love it :)
>> > ha ha. Actually I have added intentionally. But removing them across
>> > all patches as per your suggestions. :)
>>
>> /** is a syntax for KDoc, so if you want to receive automatic
== Series Details ==
Series: series starting with [01/19] drm/i915: Move request->ctx aside
URL : https://patchwork.freedesktop.org/series/43307/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4195 -> Patchwork_9025 =
== Summary - WARNING ==
Minor unknown changes coming w
Confirm we have the available HW before asserting it succeeds.
Signed-off-by: Chris Wilson
---
tests/gem_cpu_reloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/gem_cpu_reloc.c b/tests/gem_cpu_reloc.c
index 882c312d4..e3bbcd239 100644
--- a/tests/gem_cpu_reloc.c
+++ b/tests/gem_cpu
Not all HW supports XY blitter commands, so check before use.
Signed-off-by: Chris Wilson
---
lib/i915/gem_submission.c | 16
lib/i915/gem_submission.h | 3 +++
tests/gem_linear_blits.c | 1 +
tests/gem_tiled_blits.c | 1 +
tests/gem_tiled_fence_blits.c |
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
Signed-off-by: Chris Wilson
---
tests/kms_frontbuffer_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/kms_frontbuffer
On Sat, 12 May 2018, Daniel Vetter wrote:
> On Wed, May 09, 2018 at 04:32:53PM -0700, Lucas De Marchi wrote:
>> Now CC the right mailing list. The way dim sets up the repository you
>> can't have individual git configs, e.g. to set a different
>> sendemail.to for dim-tools :(
>>
>> Lucas De Mar
== Series Details ==
Series: series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before
attempting to use it
URL : https://patchwork.freedesktop.org/series/43310/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
eccae1360d6d01e73c6af2bd97122cef70820
On Mon, 14 May 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Clean up the ADPA pipe select bits. To make the whole situation a bit
> less ugly we'll start to share the same code between .get_hw_state()
> and the port state asserts.
>
> v2: Order the defines shift,mask,value (Jani)
>
> Revi
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active
On Wed, 16 May 2018, Dhinakaran Pandiyan wrote:
> On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atw...@intel.com wrote:
>> From: Matt Atwood
>>
>> According to DP spec (2.9.3.1 of DP 1.4) if
>> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
>> DPCD
>> 02200h through 0220Fh sha
On Wed, 16 May 2018, Manasi Navare wrote:
> On Wed, May 16, 2018 at 10:21:10AM -0700, Lucas De Marchi wrote:
>> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
>>
>> This fails on a Dell XPS13 9350 machine giving me just a black screen.
>> [drm:intel_dp_start_link_train [i915]] [CO
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
v2: Try using lots of subgroup+fixtures
Signed-off-by: Chris Wilson
---
tests/kms_frontbuffer_tracking.c | 58 +
Hi Dave,
Nothing too big this time either, a missing W/A added and fix
for rare HW race in addition to early IOCTL error check.
We got kthread_park related splats to CI from -rc5, so the results
are to be taken with a pinch of salt. The fix to factor around it is
bit too much for -fixes and there
== Series Details ==
Series: drm/i915/selftests: Wait longer for the old active request
URL : https://patchwork.freedesktop.org/series/43315/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4196 -> Patchwork_9026 =
== Summary - SUCCESS ==
No regressions found.
External
This should be sent to stable right?
-
Lionel
On 11/05/18 14:52, Chris Wilson wrote:
Before we unpin the buffer used for OA reports and return it to the
system, we need to be sure that the HW has finished writing into it.
For lack of a better idea, poll OACONTROL to check it is switched off.
R
On 17/05/2018 08:40, Chris Wilson wrote:
As all backends implement the same pin_count mechanism and do a
dec-and-test as their first step, pull that into the common
intel_context_unpin(). This also pulls into the caller, eliminating the
indirect call in the usual steady state case. The intel_con
Quoting Lionel Landwerlin (2018-05-17 11:18:16)
> This should be sent to stable right?
Yeah, my bad for not digging out the relevant Fixes:
+cc Joonas for the next batch.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fr
On 17/05/2018 08:40, Chris Wilson wrote:
As we want to be able to call i915_reset_engine and co from a softirq or
Just by glancing i915_reset_engine looks to heavy weight to ever be
callable from softirq/timer context. There is even a flush_workqueue in
there.
timer context, we need to be
On 17/05/2018 08:40, Chris Wilson wrote:
To be useful later, enable intel_engine_dump() to be called from irq
context (i.e. using saving and restoring irq start rather than assuming
we enter with irqs enabled).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 11 +
On 17/05/18 11:21, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-17 11:18:16)
This should be sent to stable right?
Yeah, my bad for not digging out the relevant Fixes: +cc Joonas for
the next batch. -Chris
I should have looked at it too. Was just in shock ;)
For Haswell:
Fixes: d796
On Wednesday 09 May 2018 08:29 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chro
Quoting Tvrtko Ursulin (2018-05-17 11:20:22)
>
> On 17/05/2018 08:40, Chris Wilson wrote:
> > As all backends implement the same pin_count mechanism and do a
> > dec-and-test as their first step, pull that into the common
> > intel_context_unpin(). This also pulls into the caller, eliminating the
== Series Details ==
Series: series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before
attempting to use it (rev2)
URL : https://patchwork.freedesktop.org/series/43310/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4193 -> IGTPW_1372 =
== Summary - WARNING ==
On 17/05/2018 08:40, Chris Wilson wrote:
We want to be able to reset the GPU from inside a timer callback
(hardirq context). One step requires us to copy the default context
state over to the guilty context, which means we need to plan in advance
to have that object accessible from within an ato
On 17/05/2018 08:40, Chris Wilson wrote:
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_bread
Quoting Tvrtko Ursulin (2018-05-17 11:27:20)
>
> On 17/05/2018 08:40, Chris Wilson wrote:
> > As we want to be able to call i915_reset_engine and co from a softirq or
>
> Just by glancing i915_reset_engine looks to heavy weight to ever be
> callable from softirq/timer context. There is even a fl
On Wednesday 09 May 2018 08:40 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chro
On 17/05/2018 08:40, Chris Wilson wrote:
The HWACK bit more generically solves the problem of resubmitting ESLP
while the hardware is still processing the current ELSP write. We no
longer need to check port[0].count itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 2
Hi,
I was going through drivers/gpu/drm/i915/intel_display.c to get an
understanding about how framebuffer modifiers are used in the drm
subsystem.
I could see the following in intel_framebuffer_init(),
(added in commit 2e2adb0573)
<< some code >>
switch (mode_cmd->modifier[0]) {
case I
On 17/05/2018 08:40, Chris Wilson wrote:
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
We do not chase device info but modparams in this case.
gen8_cs_irq_handler 512 428 -84
I gues
On 17/05/2018 08:40, Chris Wilson wrote:
As we are splitting processing the CSB events from submitting the ELSP,
we also need to duplicate the check that we hold a device wakeref for our
hardware access to the disjoint locations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc
== Series Details ==
Series: series starting with [01/19] drm/i915: Move request->ctx aside
URL : https://patchwork.freedesktop.org/series/43307/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4195_full -> Patchwork_9025_full =
== Summary - FAILURE ==
Serious unknown chan
Quoting Tvrtko Ursulin (2018-05-17 11:58:21)
>
> On 17/05/2018 08:40, Chris Wilson wrote:
> > Store whether or not we need to kick the guc's execlists emulation on
> > the engine itself to avoid chasing the device info.
>
> We do not chase device info but modparams in this case.
>
> > gen8_cs_ir
The HWACK bit more generically solves the problem of resubmitting ESLP
while the hardware is still processing the current ELSP write. We no
longer need to check port[0].count itself.
References: ba74cb10c775 ("drm/i915/execlists: Delay writing to ELSP until HW
has processed the previous write")
S
== Series Details ==
Series: drm/i915/execlists: HWACK checking superseded checking port[0].count
URL : https://patchwork.freedesktop.org/series/43322/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bbad01ba6ca9 drm/i915/execlists: HWACK checking superseded checking
port[0].cou
== Series Details ==
Series: drm/i915/execlists: HWACK checking superseded checking port[0].count
URL : https://patchwork.freedesktop.org/series/43322/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4196 -> Patchwork_9027 =
== Summary - WARNING ==
Minor unknown changes co
On Thu, May 17, 2018 at 11:55:47AM +0100, Ayan Halder wrote:
> Hi,
>
> I was going through drivers/gpu/drm/i915/intel_display.c to get an
> understanding about how framebuffer modifiers are used in the drm
> subsystem.
> I could see the following in intel_framebuffer_init(),
> (added in commit 2e
On Monday 14 May 2018 02:38 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
== Series Details ==
Series: drm/i915/selftests: Wait longer for the old active request
URL : https://patchwork.freedesktop.org/series/43315/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4196_full -> Patchwork_9026_full =
== Summary - WARNING ==
Minor unknown changes co
On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
On 17/05/2018 08:40, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s
On 17/05/2018 12:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-17 11:58:21)
On 17/05/2018 08:40, Chris Wilson wrote:
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
We do not chase device info but modparams
Hi Ville,
On 23 March 2018 at 14:49, Daniel Stone wrote:
> On 23 March 2018 at 14:42, Ville Syrjälä
> wrote:
>> Hmm. I'm thinking we can stick to the single reference per fb.
>> IIRC this counter is there just to prevent changes of the obj
>> tiling mode as long as any fb exists that uses the o
On Thursday 17 May 2018 06:31 PM, Ramalingam C wrote:
On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedes
On Monday 14 May 2018 03:00 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
Do not update number of enabled dbuf slices in dev_priv struct until we
actually enable/disable dbuf slice in hw. This is leading to never
updating dbuf slices and resulting in DBuf slice mismatch warning.
Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed")
Signed-off-by:
On Monday 14 May 2018 03:15 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
== Series Details ==
Series: series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before
attempting to use it (rev2)
URL : https://patchwork.freedesktop.org/series/43310/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4485_full -> IGTPW_1372_full =
== Summary - WARNIN
== Series Details ==
Series: drm/i915/icl: Don't update enabled dbuf slices struct until updated in
hw
URL : https://patchwork.freedesktop.org/series/43330/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4196 -> Patchwork_9028 =
== Summary - SUCCESS ==
No regressions fou
On 2018.05.16 17:38:30 +0100, Chris Wilson wrote:
> Quoting Mika Kuoppala (2017-03-16 09:37:44)
> > Chris Wilson writes:
> >
> > > Compute the offset of the end of the crc32 field using offsetofend()
> > > rather than open-coding.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Zhenyu Wang
>
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.0
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old
active request
URL : https://patchwork.freedesktop.org/series/43334/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ddf6fd832a10 drm/i915/selftests: Wait longer for the old activ
The command parser is feature complete, stable and required by
userspace. In commit 41736a8e3331 ("drm/i915: Use the precomputed value
for whether to enable command parsing") I accidentally removed control
from the modparam, and as no one has complained, eemove the left
over modparam completely!
R
On 17/05/18 01:23, Chris Wilson wrote:
Confirm we have the available HW before asserting it succeeds.
Signed-off-by: Chris Wilson
---
tests/gem_cpu_reloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/gem_cpu_reloc.c b/tests/gem_cpu_reloc.c
index 882c312d4..e3bbcd239 100644
--
On Thu, 17 May 2018, Chris Wilson wrote:
> The command parser is feature complete, stable and required by
> userspace. In commit 41736a8e3331 ("drm/i915: Use the precomputed value
> for whether to enable command parsing") I accidentally removed control
> from the modparam, and as no one has compla
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old
active request
URL : https://patchwork.freedesktop.org/series/43334/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9029 =
== Summary - FAILURE ==
Seriou
== Series Details ==
Series: drm/i915: Remove unused enable_cmd_parser modparam
URL : https://patchwork.freedesktop.org/series/43340/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
913921ed0c35 drm/i915: Remove unused enable_cmd_parser modparam
-:12: WARNING:COMMIT_LOG_LONG_LINE
Make sure that when we don't have any scheduler attributes for the
request the string is terminated.
Fixes: 247870ac8ea7 ("drm/i915: Build request info on stack before printk")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
1 file changed, 1 i
On Thu, 2018-05-17 at 12:50 +0300, Jani Nikula wrote:
> On Wed, 16 May 2018, Dhinakaran Pandiyan om> wrote:
> > On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atw...@intel.com
> > wrote:
> > > From: Matt Atwood
> > >
> > > According to DP spec (2.9.3.1 of DP 1.4) if
> > > EXTENDED_RECEIVER_CAPABIL
Quoting Antonio Argenziano (2018-05-17 16:08:14)
>
>
> On 17/05/18 01:23, Chris Wilson wrote:
> > Confirm we have the available HW before asserting it succeeds.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/gem_cpu_reloc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
== Series Details ==
Series: drm/i915: Remove unused enable_cmd_parser modparam
URL : https://patchwork.freedesktop.org/series/43340/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9030 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwor
== Series Details ==
Series: drm/i915/execlists: HWACK checking superseded checking port[0].count
URL : https://patchwork.freedesktop.org/series/43322/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4196_full -> Patchwork_9027_full =
== Summary - WARNING ==
Minor unknown
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.0
== Series Details ==
Series: drm/i915: Nul-terminate legacy debug string
URL : https://patchwork.freedesktop.org/series/43341/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9031 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://p
On Tue, May 15, 2018 at 04:59:26PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content type setting property to drm_connector(part 1)
> and enabled transmitting it with HDMI AVI infoframes
> for i915(part 2).
>
> Stanislav Lisovskiy (2):
> drm: content-type property for HDMI co
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old
active request
URL : https://patchwork.freedesktop.org/series/43334/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a809889d3010 drm/i915/selftests: Wait longer for the old activ
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old
active request
URL : https://patchwork.freedesktop.org/series/43334/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9032 =
== Summary - FAILURE ==
Seriou
On 17/05/18 08:37, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-17 16:08:14)
On 17/05/18 01:23, Chris Wilson wrote:
Confirm we have the available HW before asserting it succeeds.
Signed-off-by: Chris Wilson
---
tests/gem_cpu_reloc.c | 1 +
1 file changed, 1 insertion(+)
d
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old
active request
URL : https://patchwork.freedesktop.org/series/43344/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
81caf1d82050 drm/i915/selftests: Wait longer for the old activ
Quoting Antonio Argenziano (2018-05-17 17:29:26)
>
>
> On 17/05/18 08:37, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-05-17 16:08:14)
> >>
> >>
> >> On 17/05/18 01:23, Chris Wilson wrote:
> >>> Confirm we have the available HW before asserting it succeeds.
> >>>
> >>> Signed-off-by:
1 - 100 of 181 matches
Mail list logo