On Wed, Jul 19, 2017 at 04:46:07PM +0300, Paul Kocialkowski wrote:
> This introduces a common FrameDumpPath configuration field, as well as
> helper functions in dedicated igt_frame for writing cairo surfaces
> to png files.
>
> Signed-off-by: Paul Kocialkowski
> ---
> lib/Makefile.sources | 2
On Thu, Jul 20, 2017 at 8:27 AM, Ramalingam C wrote:
> Agreed Paulo. As per daniel's suggestion we tried to reuse the
> infrastructure
> provided by frontbuffer tracking igt. But we couldn't as the test case
> requirements
> were not matching.
DRRS _is_ using the frontbuffer tracking stuff. Maybe
This adds the required error clean/free calls after calling
configuration parsing functions. In addition to properly handling memory,
this avoids glib spewing out error messages on stderr, which breaks the
whole CI.
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 11 ++-
1 file cha
On Thu, 2017-07-20 at 10:45 +0300, Paul Kocialkowski wrote:
> This adds the required error clean/free calls after calling
> configuration parsing functions. In addition to properly handling
> memory,
> this avoids glib spewing out error messages on stderr, which breaks
> the
> whole CI.
Fixes: ee3
This adds the required error clean/free calls after calling
configuration parsing functions. In addition to properly handling memory,
this avoids glib spewing out error messages on stderr, which breaks the
whole CI with this message:
GLib-WARNING **: GError set over the top of a previous GErro
On Thu, Jul 20, 2017 at 11:07:42AM +0300, Paul Kocialkowski wrote:
> This adds the required error clean/free calls after calling
> configuration parsing functions. In addition to properly handling memory,
> this avoids glib spewing out error messages on stderr, which breaks the
> whole CI with this
On Wed, Jul 19, 2017 at 10:39:28AM -0700, Matthias Kaehlcke wrote:
> Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
> transcoders") misses some pieces, due to a problem with the patch
> format, this patch adds the remaining bits.
>
> Fixes: a21960339c8c ("drm/i915: Consistently
We use WC pages for coherent writes into the ppGTT on !llc
architectuures. However, to create a WC page requires a stop_machine(),
i.e. is very slow. To compensate we currently keep a per-vm cache of
recently freed pages, but we still see the slow startup of new contexts.
We can amoritize that cost
On Wed, Jul 19, 2017 at 04:01:03PM +0200, Maarten Lankhorst wrote:
> Op 19-07-17 om 14:55 schreef Daniel Vetter:
> > The core already does this in setup_commit(). With this we can also
> > remove the unpin_work_count since it's the last user.
> >
> > Cc: Maarten Lankhorst
> > Cc: Ville Syrjälä
>
On Wed, Jul 19, 2017 at 11:03:46AM +0300, Arkadiusz Hiler wrote:
> On Tue, Jul 18, 2017 at 06:00:20PM +0200, Daniel Vetter wrote:
> > There's a bunch of reasons why I think we should formalize and enforce
> > our review rules for igt patches:
> >
> > - We have a lot of new engineers joining and re
On 19/07/2017 10:53, Kamble, Sagar A wrote:
Can we reuse calc_residency defined in i915_sysfs.c
Looks like it, that is intel_pm.c/intel_rc6_residency_us.
I will incorporate the change in the series or the patch. Thanks for
spotting this!
Regards,
Tvrtko
On 7/18/2017 8:06 PM, Tvrtko Ursu
On Thu, 20 Jul 2017, Imre Deak wrote:
> The scaler allocation code depends on a non-zero default value for the
> crtc scaler_id, so make sure we initialize the scaler state accordingly
> even if the crtc is off. This fixes at least an initial YUV420 modeset
> (added in a follow-up patchset by Shas
On 19/07/2017 13:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-18 15:36:04)
From: Tvrtko Ursulin
Rough sketch of the idea I mentioned a few times to various people - merging
the engine busyness tracking with Chris i915 PMU RFC.
First patch is the actual PMU RFC by Chris. It is foll
On 19/07/2017 12:04, Chris Wilson wrote:
[snip]
Long term though having a global static key is going to be a nasty wart.
Joonas will definitely ask the question how much will it cost us to use
an engine->bool and what we can do to minimise that cost.
Why you think it is nasty? Sounds pretty
This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and
enabling DPCD backlight leads to a black screen after suspend/resume.
References: http://mid.m
The two commits being reverted regress machines, a production ThinkPad,
and BXT-P in CI, and there hasn't been adequate response to follow-up or
fix the issues. The regressions were reported 3½ weeks ago. The reverts
are long overdue already. Back to the drawing board.
BR,
Jani.
Cc: Jenny TC
Cc
This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3.
The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and
enabling DPCD backlight leads to a black screen after suspend/resume.
References: http://mid.m
On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> On Thu, 20 Jul 2017, Imre Deak wrote:
> > The scaler allocation code depends on a non-zero default value for the
> > crtc scaler_id, so make sure we initialize the scaler state accordingly
> > even if the crtc is off. This fixes at lea
On Wed, 19 Jul 2017, "Pandiyan, Dhinakaran"
wrote:
> On Wed, 2017-07-19 at 15:59 +0530, Jenny TC wrote:
>> With older panels, AUX pin for backlight doesn't work.
What evidence do you have to back up that claim?
>> On some panels, this causes backlight issues on S3 resume.
>
> What is it that we
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix scaler init during CRTC HW
state readout
URL : https://patchwork.freedesktop.org/series/27607/
State : success
== Summary ==
Series 27607v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27607/
For future reference, please post new versions of the entire series as
new threads. When posting new versions of just some individual patches,
in-reply-to each patch being replaced is fine. I think this is more
clear, and also gives patchwork a better chance to apply the right
patches for testing
On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote:
> On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> > On Thu, 20 Jul 2017, Imre Deak wrote:
> > > The scaler allocation code depends on a non-zero default value for the
> > > crtc scaler_id, so make sure we initialize the scal
== Series Details ==
Series: drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
URL : https://patchwork.freedesktop.org/series/27604/
State : success
== Summary ==
Series 27604v1 drm/i915/selftests: Fix an error handling path in
'mock_gem_device()'
https://patchwork.freedes
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, July 11, 2017 9:42 PM
> To: Srinivas, Vidya
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported
> format for sprite plane
>
> On Tu
> >> With older panels, AUX pin for backlight doesn't work.
>
> What evidence do you have to back up that claim?
Debugging further it's found that the panel I am having doesn't support AUX
Backlight.
cat /sys/kernel/debug/dri/0/eDP-1/i915_dpcd
...
0701: bb ff 00 00
With below change its
On 18/07/2017 19:48, Patchwork wrote:
== Series Details ==
Series: drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
URL : https://patchwork.freedesktop.org/series/27510/
State : success
== Summary ==
Series 27510v1 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_pri
On 19/07/2017 23:35, Christophe JAILLET wrote:
Goto the right label in case of error, otherwise there is a leak.
This has been introduced by c5cf9a9147ff. In this patch a goto has not been
updated.
Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist
from")
Sign
== Series Details ==
Series: drm/i915: Keep a small stash of preallocated WC pages
URL : https://patchwork.freedesktop.org/series/27622/
State : success
== Summary ==
Series 27622v1 drm/i915: Keep a small stash of preallocated WC pages
https://patchwork.freedesktop.org/api/1.0/series/27622/rev
Quoting Tvrtko Ursulin (2017-07-20 11:09:53)
>
> On 19/07/2017 23:35, Christophe JAILLET wrote:
> > Goto the right label in case of error, otherwise there is a leak.
> > This has been introduced by c5cf9a9147ff. In this patch a goto has not been
> > updated.
> >
> > Fixes: c5cf9a9147ff ("drm/i915
As realised by commit 9e3d6223d209 ("math64, timers: Fix 32bit
mul_u64_u32_shr() and friends"), GCC does not always generate ideal code
for performing a 32b x 32b multiply returning a 64b result (i.e. where
we idiomatically use u64 result = (u64)x * (u32)x).
Signed-off-by: Chris Wilson
---
drive
On 20/07/17 12:39, Jani Nikula wrote:
For future reference, please post new versions of the entire series as
new threads. When posting new versions of just some individual patches,
in-reply-to each patch being replaced is fine. I think this is more
clear, and also gives patchwork a better chance
As realised by commit 9e3d6223d209 ("math64, timers: Fix 32bit
mul_u64_u32_shr() and friends"), GCC does not always generate ideal code
for performing a 32b x 32b multiply returning a 64b result (i.e. where
we idiomatically use u64 result = (u64)x * (u32)x). This catches a
couple of instances in th
On Thu, Jul 20, 2017 at 11:41:35AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote:
> > On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> > > On Thu, 20 Jul 2017, Imre Deak wrote:
> > > > The scaler allocation code depends on a non-zero def
On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote:
> For future reference, please post new versions of the entire series as
> new threads. When posting new versions of just some individual
> patches,
> in-reply-to each patch being replaced is fine. I think this is more
> clear, and also gives pa
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after t
... using the biggest hammer we have. This is essentially a weaponized
version of the timeout-based wedging Chris added in
commit 36703e79a982c8ce5a8e43833291f2719e92d0d1
Author: Chris Wilson
Date: Thu Jun 22 11:56:25 2017 +0100
drm/i915: Break modeset deadlocks on reset
Because defense-i
There's no reason to entirely wedge the gpu, for the minimal deadlock
bugfix we only need to unbreak/decouple the atomic commit from the gpu
reset. The simplest way to fix that is by replacing the
unconditional fence wait a the top of commit_tail by a wait which
completes either when the fences are
The core already does this in setup_commit(). With this we can also
remove the unpin_work_count since it's the last user, and also remove
the loop since that was only used for stalling against legacy flips.
v2: Amend commit message a bit (Chris).
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed
A bit an oversight - the current code did nothing, since only
legacy flips used the unpin_work_count and assorted logic.
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 27 ++
All these races and things are now solved through the vblank evasion
trick, plus event handling is done using normal vblank even processing
and drm_crtc_arm_vblank_event. We can get rid of all this complexity.
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Signed-off-by:
Blocking in a worker is ok, that's what the unbound_wq is for. And it
unifies the paths between the blocking and nonblocking commit, giving
me just one path where I have to implement the deadlock avoidance
trickery in the next patch.
I first tried to implement the following patch without this rewo
This gets rid of all the interactions between the legacy flip code and
the modeset code. Yay!
This highlights an ommission in the atomic paths, where we fail to
apply a boost to the pending rendering when we miss the target vblank.
But the existing code is still dead and can be removed.
v2: Note
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
cleanup. However, on an overflow the pin_count bitfield will be zero,
triggering an assertion, even though we the intention is to merely warn
and report the error back to the user (as historically the culprit has
be a leak in the
== Series Details ==
Series: drm/i915: revert DPCD backlight and DBC enabling by default
URL : https://patchwork.freedesktop.org/series/27623/
State : success
== Summary ==
Series 27623v1 drm/i915: revert DPCD backlight and DBC enabling by default
https://patchwork.freedesktop.org/api/1.0/seri
If we fail to acquire a fence (for old school fenced GPU access) then we
unwind the vma reservation, including its pin. However, we were making
the execobject as holding the pin before erring out, leading to a double
unpin:
[ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287!
[ 3193.9
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mul_u32_u32() for 32b x 32b ->
64b result
URL : https://patchwork.freedesktop.org/series/27629/
State : success
== Summary ==
Series 27629v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27629
Chris Wilson writes:
> When doing a GPU reset, the CSB register will be trashed and we will
> lose any context-switch notifications that happened since the tasklet
> was disabled. If we find that all requests on this engine were
> completed, we want to make sure that the ELSP tracker is similarly
Chris Wilson writes:
> Including a check against the execlist queue before calling the engine
> idle and passing hangcheck.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/d
Quoting Mika Kuoppala (2017-07-20 13:18:40)
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 3c83f2dd6798..ad61d1998fb7 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1327,6 +1327,31 @@ static v
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC HW
state readout (rev2)
URL : https://patchwork.freedesktop.org/series/27607/
State : success
== Summary ==
Series 27607v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/ser
On Thu, Jul 20, 2017 at 1:27 PM, Paul Kocialkowski
wrote:
> On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote:
>> For future reference, please post new versions of the entire series as
>> new threads. When posting new versions of just some individual
>> patches,
>> in-reply-to each patch being
On Thu, 2017-07-20 at 14:41 +0200, Daniel Vetter wrote:
> On Thu, Jul 20, 2017 at 1:27 PM, Paul Kocialkowski
> wrote:
> > On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote:
> > > For future reference, please post new versions of the entire
> > > series as
> > > new threads. When posting new ver
Quoting Michel Thierry (2017-07-18 01:15:00)
> On 17/07/17 02:11, Chris Wilson wrote:
> > We should only ever do nop_submit_request when the machine is wedged, so
> > assert it is so.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 1 +
> > 1 file changed, 1 i
== Series Details ==
Series: series starting with [1/7] drm/i915: Avoid the gpu reset vs. modeset
deadlock
URL : https://patchwork.freedesktop.org/series/27631/
State : success
== Summary ==
Series 27631v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27631/revi
It makes debugging a massive pain.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence.c | 4 ++--
include/linux/dma-fence.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(
Quoting Michel Thierry (2017-07-18 01:22:28)
> On 17/07/17 02:11, Chris Wilson wrote:
> > Although a banned context will be told to -EIO off if they try to submit
> > more requests, we have a discrepancy between whole device resets and
> > per-engine resets where we report the GPU reset but not the
== Series Details ==
Series: drm/i915: Remove assertion from raw __i915_vma_unpin()
URL : https://patchwork.freedesktop.org/series/27632/
State : success
== Summary ==
Series 27632v1 drm/i915: Remove assertion from raw __i915_vma_unpin()
https://patchwork.freedesktop.org/api/1.0/series/27632/r
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediat
On Tue, Jul 11, 2017 at 11:42:33PM +0300, Imre Deak wrote:
> Check that all the power well IDs are unique on the given platform.
>
> v2:
> - Fix using BIT_ULL() instead of BIT() for 64 bit mask.
> v3:
> - Move the check to a separate function. (Ville)
>
> Signed-off-by: Imre Deak
Reviewed-by: Ar
On Thu, Jul 06, 2017 at 05:40:29PM +0300, Imre Deak wrote:
> Follow-up patches will add new fields to the i915_power_well struct that
> are specific to the hsw_power_well_ops helpers. Prepare for this by
> changing the generic 'data' field to a union of platform specific
> structs.
>
> Signed-off-
Chris Wilson writes:
> When doing a GPU reset, the CSB register will be trashed and we will
> lose any context-switch notifications that happened since the tasklet
> was disabled. If we find that all requests on this engine were
> completed, we want to make sure that the ELSP tracker is similarly
The get_existing macros are deprecated and should be replaced by
get_old/new_state for clarity.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h| 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 5 ++---
3 files changed, 6 inser
drm_atomic_get_existing_state should be removed, so stop using it in i915.
Fortunately all places can be converted to use the new state or old state,
even removing some dereferncing of obj->state in the process.
i915 no longer depends on plane->fb, so patch 6 removes the assignment.
The first 6 p
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediat
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediat
FBC has been converted to atomic, so updating
some legacy variables is no longer needed.
drm_atomic_helper_update_legacy_modeset_state
does update crtc->x/y anyway, but we shouldn't need it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 30 -
All the references to get_existing_state can be converted to
get_new_state or get_old_state, which means that i915 is now
get_existing_state free.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 57 +---
1 file changed, 27 insertions(+)
get_existing_crtc_state is currently unused, but the next commit
needs to access the old intel state. Rename this and use this
as convenience wrapper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/d
Remove the use of plane->state and drm_atomic_get_existing_state,
instead use the new helpers, and also add
intel_atomic_get_new_crtc_state as it's needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 22 +-
drivers/gpu/drm/i915/intel_drv.h
The previous commit added intel_atomic_get_new_crtc_state,
convert intel_fbc.c to the new helper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915
Chris Wilson writes:
> intel_engine_init_globa_seqno() may be called from an uncontrolled
> set-wedged path where we have given up waiting for broken hw and declare
> it defunct. Along that path, any sanity checks that the hw is idle
> before we adjust its state will expectedly fail, so we simply
== Series Details ==
Series: drm/i915: Only mark the execobject as pinned on success
URL : https://patchwork.freedesktop.org/series/27634/
State : failure
== Summary ==
Series 27634v1 drm/i915: Only mark the execobject as pinned on success
https://patchwork.freedesktop.org/api/1.0/series/27634
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
triggers a BUG:
[ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.74315
Chris Wilson writes:
> When we wedge the device, we clear out the in-flight requests and
> advance the breadcrumb to indicate they are complete. However, the
> breadcrumb advance includes an assert that the engine is idle, so that
> advancement needs to be the last step to ensure we pass our own
Quoting Chris Wilson (2017-07-20 14:24:29)
> If the request has been completed before the reset took effect, we don't
> need to mark it up as being a victim. Touching fence->error after the
> fence has been signaled is detected by dma_fence_set_error() and
> triggers a BUG:
>
> [ 231.743133] kern
Chris Wilson writes:
> The engine also provides a mirror of the CSB write pointer in the HWSP,
> but not of our read pointer. To take advantage of this we need to
> remember where we read up to on the last interrupt and continue off from
> there. This poses a problem following a reset, as we don'
== Series Details ==
Series: dma-fence: Don't BUG_ON when not absolutely needed
URL : https://patchwork.freedesktop.org/series/27636/
State : success
== Summary ==
Series 27636v1 dma-fence: Don't BUG_ON when not absolutely needed
https://patchwork.freedesktop.org/api/1.0/series/27636/revisions
Chris Wilson writes:
> After setting the WEDGED bit, make sure that we do wake up waiters as
> they may not be waiting for a request completion yet, just for its
> execution.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4 +++-
> 1 file
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
triggers a BUG:
[ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.74315
Quoting Mika Kuoppala (2017-07-20 14:31:31)
> Chris Wilson writes:
>
> > When we wedge the device, we clear out the in-flight requests and
> > advance the breadcrumb to indicate they are complete. However, the
> > breadcrumb advance includes an assert that the engine is idle, so that
> > advancem
Am Donnerstag, den 20.07.2017, 14:51 +0200 schrieb Daniel Vetter:
> It makes debugging a massive pain.
It is also considered very bad style to BUG the kernel on anything other
than filesystem eating catastrophic failures.
Reviewed-by: Lucas Stach
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semw
This adds missing entries for documentation generation, both for tests
and the API reference.
The list of tests is made complete and ordered alphabetically, with
modified descriptions for consistency.
More files are added to the API reference, with a minimalistic
description block added to them w
This moves the parts of the code doing env-related handling from
common_init to a new dedicated common_init_env function, making
common_init a bit more readable.
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 46 ++
1 file changed, 26 insertions
This moves all the pieces related to config parsing to the dedicated
function for this purpose, renamed common_init_config for consistency.
It allows making the common_init function less big and more readable.
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 77 ++--
On Thu, 2017-07-20 at 09:24 +0200, Daniel Vetter wrote:
> On Wed, Jul 19, 2017 at 04:46:07PM +0300, Paul Kocialkowski wrote:
> > This introduces a common FrameDumpPath configuration field, as well
> > as
> > helper functions in dedicated igt_frame for writing cairo surfaces
> > to png files.
> >
>
Chris Wilson writes:
> Quoting Mika Kuoppala (2017-07-20 14:31:31)
>> Chris Wilson writes:
>>
>> > When we wedge the device, we clear out the in-flight requests and
>> > advance the breadcrumb to indicate they are complete. However, the
>> > breadcrumb advance includes an assert that the engine
This patch adds a flowchart to the drm-misc documentation to
help committers decide which branch is most appropriate for a
given patch.
Signed-off-by: Sean Paul
---
.gitignore | 1 +
Makefile | 2 +-
drm-misc-commit-flow.dot | 22 ++
drm-misc.r
Every time we add something to debugfs, we test on the new platform
but forget to test that old platforms still work.
The test adds at most 200 ms extra time, which is worth it considering
how often we break debugfs.
Signed-off-by: Maarten Lankhorst
---
tests/intel-ci/fast-feedback.testlist | 1
emon_crash should skip if the debugfs file could not be opened the first
time, and debugfs_test.read_all_entries should skip files that could not
be opened, instead of returning an error.
This is because in a typical IGT run there may be more debugfs files
registered than can be opened.
This is a
On Wed, 19 Jul 2017, Maarten Lankhorst
wrote:
> Op 19-07-17 om 15:17 schreef Jani Nikula:
>> Another kernel, another list of failed backports.
>>
>> The following commits have been marked as Cc: stable or fixing something
>> in v4.13-rc1 or earlier, but failed to cherry-pick to
>> drm-intel-fixes
Moving to intel-gfx list, intel-gfx-bugs is mainly just for the
automated emails from bugzilla. And please let's keep the debugging in
the bug.
BR,
Jani.
On Thu, 20 Jul 2017, sdrb wrote:
> Hello,
>
> I have got some problems with intel drm frame buffer on Linux virtual
> terminals.
>
> After I
On Thu, 2017-07-20 at 01:04 +, Pandiyan, Dhinakaran wrote:
> On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote:
> > After detecting an IRQ storm, hotplug detection will switch from
> > irq-based detection to poll-based detection. After a short delay or
> > when resetting storm detectio
On Wed, 2017-07-19 at 23:11 -0700, Manasi Navare wrote:
> On Tue, Jul 18, 2017 at 03:11:42PM +0300, Paul Kocialkowski wrote:
> > On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote:
> > > After detecting an IRQ storm, hotplug detection will switch from
> > > irq-based detection to poll-based
Acked-by: Shashank Sharma
Regards
Shashank
On 7/20/2017 4:20 AM, Imre Deak wrote:
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
On Tue, Jul 18, 2017 at 11:56:23AM -0700, Puthikorn Voravootivat wrote:
> May be the older panel might not work well with this feature.
> David/Jani, what do you think about adding check that the panel is eDP
> 1.4 or later in the heuristic?
While this patch might seem correct on the surface (with
Changes since v3:
* Squashed configure.ac changes in this series
Changes since v2:
* Changed analogue in favor of analog
* Integrated analog frame match fixup in the original commit
* Rebased on top of the new revisions of the series this depends on
Changes since v1:
* Split analogue frame compar
This adds support for VGA frame comparison testing with the reference
generated from cairo. The retrieved frame from the chamelium is first
cropped, as it contains the blanking intervals, through a dedicated
helper. Another helper function asserts that the analog frame
matches or dump it to png if
This adds support for analog frame comparison check, as used in VGA.
Since VGA uses a DAC-ADC chain, its data cannot be expected to be pixel
perfect. Thus, it is impossible to uses a CRC check and full frames have
to be analyzed instead. Such an analysis is implemented, based on both
an absolute er
On Wed, 2017-07-19 at 13:50 -0400, Lyude Paul wrote:
> For both patches once you squash the configure.ac changes into the
> first one:
>
> Reviewed-by: Lyude
>
> Once you post the new versions I'll just go ahead and push them
I think it makes more sense to split the configure.ac in two parts (a
== Series Details ==
Series: drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.
URL : https://patchwork.freedesktop.org/series/27639/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generat
1 - 100 of 150 matches
Mail list logo