On Monday, April 23, 2018 8:25:02 PM PDT Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915/dp: Check if the sink crc we
> read is 6 bytes. URL : https://patchwork.freedesktop.org/series/42154/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes
On Mon, 23 Apr 2018, Dhinakaran Pandiyan wrote:
> On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
>> On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
>> > On Fri, 20 Apr 2018, Mika Kahola wrote:
>> > >
>> > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
>> > > >
>> > > > On
On Fri, 2018-04-20 at 13:56 -0700, Dhinakaran Pandiyan wrote:
> On Fri, 2018-04-20 at 11:15 -0700, Rodrigo Vivi wrote:
> >
> > On Thu, Apr 19, 2018 at 10:03:05AM +0300, Mika Kahola wrote:
> > >
> > > On Thu, 2018-04-19 at 09:11 +0300, Lofstedt, Marta wrote:
> > > >
> > > > For the PW results:
>
If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queued. The first few should be enough to help
identify a problem in execution, and most often comparing the first/last
in the queue is e
Quoting José Roberto de Souza (2018-04-19 00:41:58)
> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
> there still no sink connected it will cause
> drm_fb_helper_initial_config() to return 0 as no error happened(but
> internally the return is -EAGAIN).
> Because no frame
== Series Details ==
Series: drm/i915: Don't dump umpteen thousand requests (rev2)
URL : https://patchwork.freedesktop.org/series/42151/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4083 -> Patchwork_8784 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On 23/04/2018 18:08, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-23 17:52:54)
On 23/04/2018 14:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engi
Quoting Tvrtko Ursulin (2018-04-24 09:55:20)
>
> On 23/04/2018 18:08, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-23 17:52:54)
> >>
> >> On 23/04/2018 14:43, Chris Wilson wrote:
> >>> In the existing ABI, each engine operates its own timeline
> >>> (fence.context) and so should execute
On 24/04/2018 09:16, Chris Wilson wrote:
If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queued. The first few should be enough to help
identify a problem in execution, and most ofte
On 24/04/2018 00:16, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
v2: Move the requirements che
Quoting Tvrtko Ursulin (2018-04-24 10:27:23)
>
> On 24/04/2018 09:16, Chris Wilson wrote:
> > If we have more than a few, possibly several thousand request in the
> > queue, don't show the central portion, just the first few and the last
> > being executed and/or queued. The first few should be en
== Series Details ==
Series: drm/i915: Don't dump umpteen thousand requests (rev2)
URL : https://patchwork.freedesktop.org/series/42151/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4083_full -> Patchwork_8784_full =
== Summary - WARNING ==
Minor unknown changes coming
On 23/04/2018 19:08, Chris Wilson wrote:
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list
On 24/04/2018 10:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 10:27:23)
On 24/04/2018 09:16, Chris Wilson wrote:
If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queu
Quoting Tvrtko Ursulin (2018-04-24 10:37:03)
>
> On 23/04/2018 19:08, Chris Wilson wrote:
> > @@ -1403,14 +1406,17 @@ static void ring_retire_requests(struct intel_ring
> > *ring)
> >
> > void i915_retire_requests(struct drm_i915_private *i915)
> > {
> > - struct intel_ring *ring, *nex
On 23/04/2018 19:08, Chris Wilson wrote:
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests betwee
The patch which causes conflict:
---
From 2e8ea2777af45fe651dbd14b8b8e000e94467c24 Mon Sep 17 00:00:00 2001
From: Weinan Li
Date: Wed, 21 Mar 2018 15:40:32 +0800
Subject: [PATCH] Revert "drm/i915/gvt: set max priority for gvt context"
This reverts commit 11474e9091cf2002e948647fd9f63a7f027e488a
On Mon, Apr 23, 2018 at 08:35:05AM -0700, Lucas De Marchi wrote:
> On Mon, Apr 23, 2018 at 4:37 AM, Mika Kuoppala
> wrote:
> > We use jiffies to determine when wait expires. However
> > Imre did find out that jiffies can and will do a >1
> > increments on certain situations [1]. When this happens
Quoting Tvrtko Ursulin (2018-04-24 11:14:21)
>
> On 23/04/2018 19:08, Chris Wilson wrote:
> > -static int reserve_engine(struct intel_engine_cs *engine)
> > +static int reserve_gt(struct drm_i915_private *i915)
> > {
> > - struct drm_i915_private *i915 = engine->i915;
> > - u32 active =
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-04-23 14:03:02)
>> Chris Wilson writes:
>> > @@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct
>> > timer_list *t)
>> > if (!b->irq_armed)
>> > return;
>> >
>> > + /* If the user has disabled the fake-
On 24/04/2018 11:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 11:14:21)
On 23/04/2018 19:08, Chris Wilson wrote:
-static int reserve_engine(struct intel_engine_cs *engine)
+static int reserve_gt(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = engine->i9
Quoting Tvrtko Ursulin (2018-04-24 12:17:15)
>
> On 24/04/2018 11:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-24 11:14:21)
> >>
> >> On 23/04/2018 19:08, Chris Wilson wrote:
> >>> -static int reserve_engine(struct intel_engine_cs *engine)
> >>> +static int reserve_gt(struct drm_i91
When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +--
drivers
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where
Knowing the offset of the per-engine scratch/HWS page during boot is not
very informative, so remove the DRM_DEBUG.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu
On 24/04/2018 02:08, Chris Wilson wrote:
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf
Quoting Tvrtko Ursulin (2018-04-24 12:57:41)
>
> On 24/04/2018 02:08, Chris Wilson wrote:
> > printk unhelpfully inserts a '\n' between consecutive calls, and since
> > our drm_printf wrapper may be emitting info a seq_file instead,
> > KERN_CONT is not an option. To work with any drm_printf desti
On 24/04/2018 12:52, Chris Wilson wrote:
Knowing the offset of the per-engine scratch/HWS page during boot is not
very informative, so remove the DRM_DEBUG.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers
Use i915.dmc_firmware_path to override default firmware for the platform
and bypassing version checks.
v2: add missing param struct member declaration (David)
Tested-by: David Weinehall
Reviewed-by: David Weinehall
Cc: Anusha Srivatsa
Cc: David Weinehall
Signed-off-by: Jani Nikula
---
drive
On Mon, Apr 23, 2018 at 06:44:53AM +, Lisovskiy, Stanislav wrote:
>
> > This table is seriously deprecated, because it's unreadable and
> > unmaintainable. Quoting from the docs:
>
> > "Because this table is very unwieldy, do not add any new properties here.
> > Instead document them in a sec
== Series Details ==
Series: series starting with [1/2] drm/rect: Add midpoint to scale calculation
functions
URL : https://patchwork.freedesktop.org/series/42186/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aca1294901eb drm/rect: Add midpoint to scale calculation functions
On 20/04/18 19:55, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Use ktime on wait_for
> URL : https://patchwork.freedesktop.org/series/42035/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4072_full -> Patchwork_8764_full
Quoting Chris Wilson (2018-04-24 02:08:39)
> printk unhelpfully inserts a '\n' between consecutive calls, and since
> our drm_printf wrapper may be emitting info a seq_file instead,
> KERN_CONT is not an option. To work with any drm_printf destination, we
> need to build up the output into a tempor
Chris Wilson writes:
> Ideally, we want to atomically flush and disable the tasklet before
> resetting the GPU. At present, we rely on being the only part to touch
> our tasklet and serialisation of the reset process to ensure that we can
> suspend the tasklet from the mix of reset/wedge pathways
Quoting Mika Kuoppala (2018-04-24 13:26:11)
> Chris Wilson writes:
>
> > Ideally, we want to atomically flush and disable the tasklet before
> > resetting the GPU. At present, we rely on being the only part to touch
> > our tasklet and serialisation of the reset process to ensure that we can
> >
== Series Details ==
Series: series starting with [1/2] drm/rect: Add midpoint to scale calculation
functions
URL : https://patchwork.freedesktop.org/series/42186/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4084 -> Patchwork_8785 =
== Summary - SUCCESS ==
No regressi
Martin Peres writes:
> On 20/04/18 19:55, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [1/2] drm/i915: Use ktime on wait_for
>> URL : https://patchwork.freedesktop.org/series/42035/
>> State : failure
>>
>> == Summary ==
>>
>> = CI Bug Log - changes from CI_DRM
== Series Details ==
Series: drm/i915: Skip printing global offsets for per-engine scratch pages
URL : https://patchwork.freedesktop.org/series/42187/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4084 -> Patchwork_8786 =
== Summary - SUCCESS ==
No regressions found.
On Fri, Apr 20, 2018 at 07:56:34PM +0200, Thomas Hellstrom wrote:
> On 04/20/2018 08:51 AM, Daniel Vetter wrote:
> > Control nodes are no more!
> >
> > Signed-off-by: Daniel Vetter
> > Cc: VMware Graphics
> > Cc: Sinclair Yeh
> > Cc: Thomas Hellstrom
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx
From: Ville Syrjälä
We're currently failing to reset everything in display_info.hdmi
which will potentially cause us to use stale information when
swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
with a HDMI 1.x monitor we will continue to think that the monitor
supports scrambling.
Quoting Tvrtko Ursulin (2018-04-24 10:40:57)
>
> On 24/04/2018 10:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-24 10:27:23)
> >>
> >> On 24/04/2018 09:16, Chris Wilson wrote:
> >>> If we have more than a few, possibly several thousand request in the
> >>> queue, don't show the centr
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/ac
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
Quoting Chris Wilson (2018-04-24 14:14:11)
> In the next patch, rings are the central timeline as requests may jump
> between engines. Therefore in the future as we retire in order along the
> engine timeline, we may retire out-of-order within a ring (as the ring now
> occurs along multiple engines
Quoting Gustavo A. R. Silva (2018-04-24 14:15:45)
> There is a potential execution path in which variable err is
> returned without being properly initialized previously.
>
> Fix this by initializing variable err to 0.
err is only returned along an error path, returning 0 would not be
useful. Whi
On Mon, 2018-04-23 at 19:56 -0700, Dhinakaran Pandiyan wrote:
> Sink crc is calculated by the sink for static frames irrespective of
> what the driver sets in TEST_SINK_START dpcd. Since PSR is the only
> use
> case for sink crc, we don't really need the sink_crc_{start, stop}
> code.
>
> The seco
On 04/24/2018 03:01 PM, Daniel Vetter wrote:
On Fri, Apr 20, 2018 at 07:56:34PM +0200, Thomas Hellstrom wrote:
On 04/20/2018 08:51 AM, Daniel Vetter wrote:
Control nodes are no more!
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/d
There is a potential execution path in which variable err is
returned without being properly initialized previously.
Fix this by initializing variable err to 0.
Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable")
Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets
Quoting Gustavo A. R. Silva (2018-04-24 14:30:58)
>
>
> On 04/24/2018 08:22 AM, Chris Wilson wrote:
> > Quoting Gustavo A. R. Silva (2018-04-24 14:15:45)
> >> There is a potential execution path in which variable err is
> >> returned without being properly initialized previously.
> >>
> >> Fix th
== Series Details ==
Series: drm/i915: add support for specifying DMC firmware override by module
param (rev3)
URL : https://patchwork.freedesktop.org/series/34157/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c62c2ab8334b drm/i915: add support for specifying DMC firmware ove
On 04/24/2018 08:22 AM, Chris Wilson wrote:
Quoting Gustavo A. R. Silva (2018-04-24 14:15:45)
There is a potential execution path in which variable err is
returned without being properly initialized previously.
Fix this by initializing variable err to 0.
err is only returned along an error
On 24/04/2018 12:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 12:17:15)
On 24/04/2018 11:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 11:14:21)
On 23/04/2018 19:08, Chris Wilson wrote:
-static int reserve_engine(struct intel_engine_cs *engine)
+static int reserv
== Series Details ==
Series: drm/i915: add support for specifying DMC firmware override by module
param (rev3)
URL : https://patchwork.freedesktop.org/series/34157/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4086 -> Patchwork_8787 =
== Summary - SUCCESS ==
No regress
Quoting Tvrtko Ursulin (2018-04-24 14:55:51)
>
> On 24/04/2018 12:28, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-24 12:17:15)
> >>
> >> On 24/04/2018 11:40, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-04-24 11:14:21)
>
> On 23/04/2018 19:08, Chris Wilson wrote:
>
Imre Deak writes:
> On Fri, Apr 20, 2018 at 11:27:55AM +0100, Chris Wilson wrote:
>> Quoting Mika Kuoppala (2018-04-20 10:54:26)
>> > We use jiffies to determine when wait expires. However
>> > Imre did find out that jiffies can and will do a >1
>> > increments on certain situations [1]. When thi
On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're currently failing to reset everything in display_info.hdmi
> which will potentially cause us to use stale information when
> swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor
> with a HDMI
== Series Details ==
Series: drm/edid: Reset more of the display info
URL : https://patchwork.freedesktop.org/series/42191/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4086 -> Patchwork_8788 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patc
On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We're currently failing to reset everything in display_info.hdmi
> > which will potentially cause us to use stale information when
> > sw
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
On 24/04/2018 14:14, Chris Wilson wrote:
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), lead
On 24/04/2018 15:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 14:55:51)
On 24/04/2018 12:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 12:17:15)
On 24/04/2018 11:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-24 11:14:21)
On 23/04/2018 19:08, Chris Wil
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42192/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9a8374d0cd41 drm/i915: Stop tracking timeline->inflight_seqnos
-:17: ER
On Tue, 24 Apr 2018, Chris Wilson wrote:
> Quoting José Roberto de Souza (2018-04-19 00:41:58)
>> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
>> there still no sink connected it will cause
>> drm_fb_helper_initial_config() to return 0 as no error happened(but
>> inter
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42192/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/dr
On 24/04/2018 15:46, Tvrtko Ursulin wrote:
On 24/04/2018 14:14, Chris Wilson wrote:
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the
Quoting Tvrtko Ursulin (2018-04-24 15:46:49)
>
> On 24/04/2018 14:14, Chris Wilson wrote:
> > In the next patch, rings are the central timeline as requests may jump
> > between engines. Therefore in the future as we retire in order along the
> > engine timeline, we may retire out-of-order within a
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42192/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4087 -> Patchwork_8789 =
== Summary - FAILURE ==
Serious unknown
== Series Details ==
Series: series starting with [1/2] drm/rect: Add midpoint to scale calculation
functions
URL : https://patchwork.freedesktop.org/series/42186/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4084_full -> Patchwork_8785_full =
== Summary - FAILURE ==
S
== Series Details ==
Series: drm/i915: Skip printing global offsets for per-engine scratch pages
URL : https://patchwork.freedesktop.org/series/42187/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4084_full -> Patchwork_8786_full =
== Summary - FAILURE ==
Serious unknown
On Tue, 24 Apr 2018, Luc Van Oostenryck wrote:
> All implementations of the method intel_dvo_dev_ops::mode_valid(), as
> well as the underlying struct drm_connector_helper_funcs::mode_valid()
> use 'enum drm_mode_status' for the method's return type but the
> declaration of intel_dvo_dev_ops::mode
On Tue, Apr 24, 2018 at 01:36:32PM +0200, Maarten Lankhorst wrote:
> When calculating limits we want to be as pessimistic as possible,
> so we have to explicitly say whether we want to round up or down
> to accurately calculate whether we are below min_scale or above
> max_scale.
>
> Signed-off-by
All implementations of the method intel_dvo_dev_ops::mode_valid(), as
well as the underlying struct drm_connector_helper_funcs::mode_valid()
use 'enum drm_mode_status' for the method's return type but the
declaration of intel_dvo_dev_ops::mode_valid() uses an 'int' for it.
Fix this by using 'enum
== Series Details ==
Series: drm/i915/selftests: Fix uninitialized variable
URL : https://patchwork.freedesktop.org/series/42194/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4087 -> Patchwork_8790 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:
Op 24-04-18 om 17:21 schreef Ville Syrjälä:
> On Tue, Apr 24, 2018 at 01:36:32PM +0200, Maarten Lankhorst wrote:
>> When calculating limits we want to be as pessimistic as possible,
>> so we have to explicitly say whether we want to round up or down
>> to accurately calculate whether we are below m
On Tue, Apr 24, 2018 at 01:36:33PM +0200, Maarten Lankhorst wrote:
> With the previous patch drm_atomic_helper_check_plane_state correctly
> calculates clipping and the xf86-video-intel ddx is fixed to fall back
> to GPU correctly when SetPlane fails, we can remove the hack where
> we try to pan/zo
== Series Details ==
Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev3)
URL : https://patchwork.freedesktop.org/series/40825/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4087 -> Patchwork_8791 =
== Summary - SUCCESS ==
No regressions found.
Ex
== Series Details ==
Series: drm/i915: fix intel_dvo_dev_ops::mode_valid's return type
URL : https://patchwork.freedesktop.org/series/42209/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e19139a5a800 drm/i915: fix intel_dvo_dev_ops::mode_valid's return type
-:25: CHECK:PARENTHE
On Tue, Apr 24, 2018 at 05:11:37PM +0200, Maarten Lankhorst wrote:
> Op 24-04-18 om 17:21 schreef Ville Syrjälä:
> > On Tue, Apr 24, 2018 at 01:36:32PM +0200, Maarten Lankhorst wrote:
> >> When calculating limits we want to be as pessimistic as possible,
> >> so we have to explicitly say whether we
Quoting Tvrtko Ursulin (2018-04-24 15:48:10)
>
> On 24/04/2018 15:04, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-24 14:55:51)
> >>
> >> On 24/04/2018 12:28, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-04-24 12:17:15)
>
> On 24/04/2018 11:40, Chris Wilson wrote:
>
== Series Details ==
Series: drm/i915: fix intel_dvo_dev_ops::mode_valid's return type
URL : https://patchwork.freedesktop.org/series/42209/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4087 -> Patchwork_8792 =
== Summary - SUCCESS ==
No regressions found.
External U
On 04/20/2018 01:53 PM, Rodrigo Vivi wrote:
On Fri, Apr 20, 2018 at 01:49:45PM -0700, Oscar Mateo wrote:
On 04/20/2018 01:46 PM, Rodrigo Vivi wrote:
On Fri, Apr 20, 2018 at 01:33:54PM -0700, Oscar Mateo wrote:
Disable GWL clock gating to prevent two different issues that
might cause hangs.
On 13 April 2018 at 11:00, Daniel Vetter wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in
== Series Details ==
Series: drm/i915: add support for specifying DMC firmware override by module
param (rev3)
URL : https://patchwork.freedesktop.org/series/34157/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4086_full -> Patchwork_8787_full =
== Summary - WARNING ==
== Series Details ==
Series: drm/edid: Reset more of the display info
URL : https://patchwork.freedesktop.org/series/42191/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4086_full -> Patchwork_8788_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwor
On Tue, 2018-04-24 at 16:26 +0300, Mika Kahola wrote:
> On Mon, 2018-04-23 at 19:56 -0700, Dhinakaran Pandiyan wrote:
> > Sink crc is calculated by the sink for static frames irrespective of
> > what the driver sets in TEST_SINK_START dpcd. Since PSR is the only
> > use
> > case for sink crc, we do
== Series Details ==
Series: drm/i915/selftests: Fix uninitialized variable
URL : https://patchwork.freedesktop.org/series/42194/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4087_full -> Patchwork_8790_full =
== Summary - FAILURE ==
Serious unknown changes coming with
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov wrote:
> On 13 April 2018 at 11:00, Daniel Vetter wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
>>
>> We also tend to not re
== Series Details ==
Series: drm/i915/breadcrumbs: Keep the fake irq armed across reset (rev3)
URL : https://patchwork.freedesktop.org/series/40825/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4087_full -> Patchwork_8791_full =
== Summary - FAILURE ==
Serious unknown c
On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We're currently failing to reset everything in display_info.hdmi
Quoting Patchwork (2018-04-24 20:02:06)
> == Series Details ==
>
> Series: drm/i915/selftests: Fix uninitialized variable
> URL : https://patchwork.freedesktop.org/series/42194/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4087_full -> Patchwork_8790_full =
>
> =
On Wed, 2018-04-11 at 19:42 -0400, Lyude Paul wrote:
> Does what it says on the label, it's a little confusing debugging atomic
> check failures otherwise.
>
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_atomic.c | 5 -
> 1 file changed,
On 04/24/2018 02:42 PM, Chris Wilson wrote:
Quoting Patchwork (2018-04-24 20:02:06)
== Series Details ==
Series: drm/i915/selftests: Fix uninitialized variable
URL : https://patchwork.freedesktop.org/series/42194/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4087_full
== Series Details ==
Series: drm/i915: fix intel_dvo_dev_ops::mode_valid's return type
URL : https://patchwork.freedesktop.org/series/42209/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4087_full -> Patchwork_8792_full =
== Summary - FAILURE ==
Serious unknown changes c
On Mon, Apr 23, 2018 at 07:56:57PM -0700, Dhinakaran Pandiyan wrote:
> We attempt to read 6 bytes, make sure we have.
>
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --gi
On Mon, Apr 23, 2018 at 07:56:58PM -0700, Dhinakaran Pandiyan wrote:
> Sink crc is calculated by the sink for static frames irrespective of
> what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
> case for sink crc, we don't really need the sink_crc_{start, stop} code.
>
> The s
On Mon, Apr 23, 2018 at 07:56:59PM -0700, Dhinakaran Pandiyan wrote:
> With sink-crc now being relevant only for PSR static frames, move the
> code to intel_psr.c and rename the function.
>
> Signed-off-by: Dhinakaran Pandiyan
Acked-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.
1 - 100 of 119 matches
Mail list logo
