Remove never used BSM{,_MASK}. BSM_MASK #define also causes a warning.
include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshiftoverflow=]
#define INTEL_BSM_MASK (0x << 20)
Reported-by: Linus Torvalds
Signed-off-by:
On Wed, Oct 12, 2016 at 10:18:54AM +0300, Joonas Lahtinen wrote:
> Remove never used BSM{,_MASK}. BSM_MASK #define also causes a warning.
>
> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
> requires 37 bits to represent, but ‘int’ only has 32 bits
> [-Wshiftoverflow=]
>#define
On ke, 2016-10-12 at 08:42 +0100, Chris Wilson wrote:
> greps ok.
> Reviewed-by: Chris Wilson
Merged, thanks for the review.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.
No functional change. Just printing the number of active links without
stating what the number means is not very useful. So, add relevant text.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp_mst.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/d
On Tue, Oct 11, 2016 at 02:21:37PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 960 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.c
On Tue, Oct 11, 2016 at 02:21:36PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> More .rodata string saving by avoid __I915__ magic inside WARNs.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
Note that once
On 12/10/2016 09:17, David Weinehall wrote:
On Tue, Oct 11, 2016 at 02:21:36PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
More .rodata string saving by avoid __I915__ magic inside WARNs.
v2: Add parantheses around dev_priv. (Ville Syrjala)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: D
On ti, 2016-10-11 at 14:32 +0100, Chris Wilson wrote:
> In the next patch, I want to conditionally compile i915_gpu_error.c and
> that requires moving the functions used by debug out of
> i915_gpu_error.c!
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas
In the next patch, I want to conditionally compile i915_gpu_error.c and
that requires moving the functions used by debug out of
i915_gpu_error.c!
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h
Our error states are quickly growing, pinning kernel memory with them.
The majority of the space is taken up by the error objects. These
compress well using zlib and without decode are mostly meaningless, so
encoding them does not hinder quickly parsing the error state for
familiarity.
v2: Make th
Since the GTT provides universal access to any GPU page, we can use it
to reduce our plethora of read methods to just one. It also has the
important characteristic of being exactly what the GPU sees - if there
are incoherency problems, seeing the batch as executed (rather than as
trapped inside the
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under
Leave all the pretty printing to userspace and simplify the error
capture to only have a single common object printer. It makes the kernel
code more compact, and the refactoring allows us to apply more complex
transformations like compressing the output.
Signed-off-by: Chris Wilson
Reviewed-by: J
We currently capture the GPU state after we detect a hang. This is vital
for us to both triage and debug hangs in the wild (post-mortem
debugging). However, it comes at the cost of running some potentially
dangerous code (since it has to make very few assumption about the state
of the driver) that
On Tue, Oct 11, 2016 at 02:21:35PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This saves 1872 bytes of .rodata strings.
>
> v2:
> * Rebase.
> * Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu
== Series Details ==
Series: drm/i915/dp: Debug log MST active links explicitly
URL : https://patchwork.freedesktop.org/series/13627/
State : warning
== Summary ==
Series 13627v1 drm/i915/dp: Debug log MST active links explicitly
https://patchwork.freedesktop.org/api/1.0/series/13627/revisions
On a laptop that tracks the latest stable release (Ie, it now runs
v4.8.1) I see this WARNING
WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
Full trace pasted below. I never saw this WARNING before v4.8. Since
v4.8 I've had it in all (four, actually) boots.
What am I expected to do about thi
On Wed, Oct 12, 2016 at 09:43:02AM +0100, Tvrtko Ursulin wrote:
>
> On 12/10/2016 09:17, David Weinehall wrote:
> > On Tue, Oct 11, 2016 at 02:21:36PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > More .rodata string saving by avoid __I915__ magic inside WARNs.
> > >
> > >
On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-07 at 10:38 +0300, Jani Nikula wrote:
> > The "change" to use bash just reflects current reality. All the changes
> > here look simple and sane, and immediately improve the results. The work
> > is already done, no us
Hi Linus/Andrew,
This patch has been waiting for feedback or merging for ~8 months now.
It was posted to linux-ker...@vger.kernel.org initially and got an
immediate Acked-by. After no other feedback, I revised the assumed
maintainers and still no reactions. Next I changed over to
triv...@kernel.or
On Tue, Oct 11, 2016 at 02:21:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This saves 3248 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
Reviewed-by: David Weinehall
How come you didn't do HAS_PCH_LPT_{LP,H} together with
the rest of the PC
On Tue, Oct 11, 2016 at 02:21:41PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 848 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.c
On Tue, Oct 11, 2016 at 02:21:40PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 4472 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
Reviewed-by: David Weinehall
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv.c
On Tue, Oct 11, 2016 at 02:21:45PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 1016 bytes of .rodata strings and couple hundred of .text.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> driver
On Tue, Oct 11, 2016 at 02:21:43PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 2432 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h
On Tue, Oct 11, 2016 at 06:49:46PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Trust VBT aux/ddc information
> URL : https://patchwork.freedesktop.org/series/13600/
> State : warning
>
> == Summary ==
>
> Series 13600v1 drm/i915: Trust VBT aux/ddc information
> https:/
On Tue, Oct 11, 2016 at 02:21:47PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 472 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Move common code out of
i915_gpu_error.c
URL : https://patchwork.freedesktop.org/series/13630/
State : failure
== Summary ==
Series 13630v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/13630/r
On Tue, Oct 11, 2016 at 10:04:00PM +0200, Maarten Maathuis wrote:
> My name does not include the word "show" (Tested-by tag).
Sorry about that. Some copy-paste fail I suspect. I'll fix it up.
And you actually tested the v1 patches, so I totally forgot to note that
in the tested-by tags :( Care to
On ke, 2016-10-12 at 13:12 +0300, David Weinehall wrote:
> On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
> > I'm against converting to bash/python for no
> > benefit.
>
> +1, Insightful.
>
> Most of the bashisms seem to be simple cases of the superfluous
> "function" in front o
On ke, 2016-10-12 at 11:56 +0200, Paul Bolle wrote:
> On a laptop that tracks the latest stable release (Ie, it now runs
> v4.8.1) I see this WARNING
> WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
>
> Full trace pasted below. I never saw this WARNING before v4.8. Since
> v4.8 I've had it in
During rpm resume we restore the fences, but we do not have the
protection of struct_mutex. This rules out updating the activity
tracking on the fences, and requires us to rely on the rpm as the
serialisation barrier instead.
[ 350.298052] [drm:intel_runtime_resume [i915]] Resuming device
[ 350.
On Wed, 12 Oct 2016, David Weinehall wrote:
> On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
>> On pe, 2016-10-07 at 10:38 +0300, Jani Nikula wrote:
>> > The "change" to use bash just reflects current reality. All the changes
>> > here look simple and sane, and immediately improv
We can remove the false coupling between RPM and struct mutex by the
observation that we can use the RPM wakeref as the barrier around user
mmap access. That is as we tear down the user's PTE atomically from
within rpm suspend and then to fault in new PTE requires the rpm
wakeref, means that no use
Now that we have reduced the access to the list to either (a) under the
struct_mutex whilst holding the RPM wakeref (so that concurrent writers to
the list are serialised by struct_mutex) and (b) under the atomic
runtime suspend (which cannot run concurrently with any other accessor due
to the atom
We want to decouple RPM and struct_mutex, but currently RPM has to walk
the list of bound objects and remove userspace mmapping before we
suspend (otherwise userspace may continue to access the GTT whilst it is
powered down). This currently requires the struct_mutex to walk the
bound_list, but if w
The current meaning of whether an object has a GGTT vma is very
ill-defined (and note we don't check for any partials either), it just
means that at some point it was in the GGTT but it may not be now. The
information we really care about here is whether it is taking up
precious mappable aperture s
'\n' is supposed to be at the end of the line, not in the middle.
Fixes: cdb324bde570 ("drm/i915: Show bounds of active request in the ring...")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote:
> If you really care, go ahead and send the patches to make these Bourne
> shell compatible, but then do also sign up for testing them on non-bash
> shells. The CI won't. I don't think it's worth the trouble, but YMMV.
If they're re-written usin
From: Ville Syrjälä
We occasionally depend on eg. to_intel_crtc(NULL) being NULL as
well. Sprinkle in some BUILD_BUG_ON()s to make sure we don't
accidentally change things in a way that would violate this
assumption.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 +++
On ti, 2016-10-11 at 12:03 -0700, Robert Bragg wrote:
> > > + case DRM_I915_PERF_PROP_MAX:
> > > + BUG();
> >
> > We already handle this case above, but I guess we still need this in
> > order to silence gcc...
>
> right, and preferable to having a default: cas
On Tue, Oct 11, 2016 at 02:21:44PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 1320 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.c
This was already;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On ke, 2016-10-12 at 12:16 +0100, Chris Wilson wrote:
> The current meaning of whether an object has a GGTT vma is very
> ill-defined (and note we don't check for any partials either), it just
> means that at some point it was in the GGTT but it may not be now. The
> information we really care abou
On Tue, Oct 11, 2016 at 02:21:48PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 472 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h
On Tue, Oct 11, 2016 at 02:21:51PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 968 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h
From: Ville Syrjälä
GMBUS is part of the display engine, and thus has no need for
forcewake. Let's not bother trying to grab it then.
I don't recall if the display engine suffers from system hangs
due to multiple accesses to the same "cacheline" in mmio space.
I hope not since we're no longer pr
During rpm resume we restore the fences, but we do not have the
protection of struct_mutex. This rules out updating the activity
tracking on the fences, and requires us to rely on the rpm as the
serialisation barrier instead.
[ 350.298052] [drm:intel_runtime_resume [i915]] Resuming device
[ 350.
The current meaning of whether an object has a GGTT vma is very
ill-defined (and note we don't check for any partials either), it just
means that at some point it was in the GGTT but it may not be now. The
information we really care about here is whether it is taking up
precious mappable aperture s
On Tue, Oct 11, 2016 at 02:21:52PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 1416 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
Do note though, that this is a *very* large
On Tue, Oct 11, 2016 at 02:21:50PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 944 bytes of .rodata strings and 128 bytes of .text.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/
On Tue, Oct 11, 2016 at 02:21:46PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 1392 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
This patch does quite a bit more than just change IS_BROXTON to use
dev_pr
On Wed, Oct 12, 2016 at 02:44:47PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> GMBUS is part of the display engine, and thus has no need for
> forcewake. Let's not bother trying to grab it then.
>
> I don't recall if the display engine suffers from system hangs
> due to
Signed-off-by: Abdiel Janulgue
---
tests/gem_wait.c | 77 +---
1 file changed, 12 insertions(+), 65 deletions(-)
diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index 461efdb..24a5f5e 100644
--- a/tests/gem_wait.c
+++ b/tests/gem_wait.c
@@ -54
Generalized from auto-tuned GPU dummy workload in gem_wait and kms_flip
Signed-off-by: Abdiel Janulgue
---
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_dummyload.c | 419 +++
lib/igt_dummyload.h | 63
4 files chan
Signed-off-by: Abdiel Janulgue
---
tests/kms_flip.c | 191 +++
1 file changed, 10 insertions(+), 181 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 065ad66..93cf391 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1
A lot of igt testcases need some dummy load to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overtly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that is dynamically
On Tue, Oct 11, 2016 at 02:21:39PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 944 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4
On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> start.
That would be between v4.7 and v4.8. (I guess my report was ambiguous.)
That might take some time. Because bisecting always takes a long time
and especially
On 12/10/2016 12:52, David Weinehall wrote:
On Tue, Oct 11, 2016 at 02:21:46PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Saves 1392 bytes of .rodata strings.
v2: Add parantheses around dev_priv. (Ville Syrjala)
Signed-off-by: Tvrtko Ursulin
This patch does quite a bit more than ju
On Tue, Oct 11, 2016 at 02:21:42PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 1808 bytes of .rodata strings.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.c
On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote:
> Signed-off-by: Abdiel Janulgue
> ---
> tests/gem_wait.c | 77
> +---
> 1 file changed, 12 insertions(+), 65 deletions(-)
We can do so much better than a dummy load here. We can
On Tue, Oct 11, 2016 at 02:21:49PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Saves 864 bytes of .rodata strings and ~100 of .text.
>
> v2: Add parantheses around dev_priv. (Ville Syrjala)
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i
The test is producing a lot of CI noise.
Signed-off-by: Petri Latvala
---
Will be pushed shortly. Visible in CI results tomorrow-ish.
tests/intel-ci/fast-feedback.testlist | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/intel-ci/fast-feedback.testlist
b/tests/intel-ci/fast-feedback.t
== Series Details ==
Series: series starting with [1/5] drm/i915: Use fence_write() from rpm resume
URL : https://patchwork.freedesktop.org/series/13636/
State : warning
== Summary ==
Series 13636v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/13636/revisions/1/
Since "Dynamic page table allocations" were introduced, our page tables
can grow (being dynamically allocated) with address space range usage.
Unfortunately, their lifetime is bound to vm. This is not a huge problem
when we're not using softpin - drm_mm is creating an upper bound on used
range by c
We never used any invalid ptes, those were put in place for
a possibility of doing gpu faults. However our batchbuffers are not
restricted in length, so everything needs to be pointing to something
and thus out-of-bounds is pointing to scratch.
Remove the valid flag as it is always true.
v2: Expa
Let's use more top-down approach, where each gen8_ppgtt_clear_* function
is responsible for clearing the struct passed as an argument and calling
relevant clear_range functions on lower-level tables.
Doing this rather than operating on PTE ranges makes the implementation
of shrinking page tables qu
On Wed, Oct 12, 2016 at 12:58:34PM +0100, Chris Wilson wrote:
> On Wed, Oct 12, 2016 at 02:44:47PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > GMBUS is part of the display engine, and thus has no need for
> > forcewake. Let's not bother trying to grab it then.
> >
This is a testcase with multiple planes. The idea here is the following
- draw a uniform frame with blue color
- grab crc for reference
- put planes randomly on top with the same blue color
- punch holes with black color into the primary framebuffer
- ideally the planes should cover these hol
Treat a framebuffer reference with the same priority as an active
reference whilst shrinking. Framebuffers are likely to be reused and
typically cost more to migrate to and from GPU memory (on LLC
architectures we need to clflush), so defer the temptation to purge them
during a kswapd run until we
On Wed, Oct 12, 2016 at 01:06:51PM +0100, Tvrtko Ursulin wrote:
>
> On 12/10/2016 12:52, David Weinehall wrote:
> > On Tue, Oct 11, 2016 at 02:21:46PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Saves 1392 bytes of .rodata strings.
> > >
> > > v2: Add parantheses around
On Wed, Oct 12, 2016 at 03:39:47PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 12, 2016 at 12:58:34PM +0100, Chris Wilson wrote:
> > On Wed, Oct 12, 2016 at 02:44:47PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > GMBUS is part of the display engine, and thu
On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> @@ -871,7 +845,7 @@ shmem_clflush_swizzled_range(char *addr, unsigned long
> length,
> /* Only difference to the fast-path function is that this can handle bit17
> * and uses non-atomic copy and kmap functions. */
> static int
> -shmem_pr
Op 07-10-16 om 13:45 schreef Mika Kahola:
> This is a testcase with multiple planes. The idea here is the following
>
> - draw a uniform frame with blue color
> - grab crc for reference
> - put planes randomly on top with the same blue color
> - punch holes with black color into the primary fra
== Series Details ==
Series: drm/i915: Fix misplaced '\n' in printing the GPU error's RING_HEAD
URL : https://patchwork.freedesktop.org/series/13639/
State : warning
== Summary ==
Series 13639v1 drm/i915: Fix misplaced '
' in printing the GPU error's RING_HEAD
https://patchwork.freedesktop.org
On Wed, 12 Oct 2016, Joonas Lahtinen wrote:
> On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote:
>> If you really care, go ahead and send the patches to make these Bourne
>> shell compatible, but then do also sign up for testing them on non-bash
>> shells. The CI won't. I don't think it's worth
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> pass -> DMESG-WARN (fi-skl-6770hq)
[ 468.807117] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU about
cdclk change
[ 468.816844] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU
pipe C FIFO u
On Wed, Oct 12, 2016 at 04:04:34PM +0300, Jani Nikula wrote:
> On Wed, 12 Oct 2016, Joonas Lahtinen wrote:
> > On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote:
> >> If you really care, go ahead and send the patches to make these Bourne
> >> shell compatible, but then do also sign up for testin
== Series Details ==
Series: drm/i915: Make sure the base lives at offset 0 of all kms objects
URL : https://patchwork.freedesktop.org/series/13640/
State : failure
== Summary ==
Series 13640v1 drm/i915: Make sure the base lives at offset 0 of all kms objects
https://patchwork.freedesktop.org/
This is the last bit required for making nonblocking modesets work
correctly. The state in intel_crtc->hw_ddb is not updated until
somewhere in atomic commit, while the previous crtc state should be
accurate if the ddb hasn't changed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/int
Move calculating minimum allocations to a helper, which cleans up the
code some more. The cursor is still allocated in advance because it
doesn't count towards data rate and should always be reserved.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 66 +
Instead of running the watermark updates from the callbacks run
them from a separate hook atomic_evade_watermarks.
This also gets rid of the global skl_results, which was required for
keeping track of the current atomic commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.
This is not required any more now that we get fresh state from
drm_atomic_crtc_state_for_each_plane_state. Zero all state
in advance.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 4
drivers/gpu/drm/i915/intel_pm.c | 15 +--
2 files changed, 5 inserti
Caching is not required, drm_atomic_crtc_state_for_each_plane_state
can be used to inspect all plane_states that are assigned to the
current crtc_state, so we can just recalculate every time.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 27 ---
1
It's only used in one function, and can be calculated without caching it
in the global struct by using drm_atomic_crtc_state_for_each_plane_state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 4
drivers/gpu/drm/i915/intel_pm.c | 44 +++---
This patch series applies on top of Lyude's patches.
They clean up the remainder of SKL style wm's, and finally makes
SKL watermarks ready for nonblocking modeset by using the crtc_state
for watermarks as much as possible.
Maarten Lankhorst (8):
drm/i915/skl+: Prepare for removing data rate from
Allow the driver to write watermarks during atomic evasion.
This will make it possible to write the watermarks in a cleaner
way on gen9+.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/intel_display.c | 18 --
drivers/g
There's no need to keep a duplicate skl_pipe_wm around any more,
everything can be discovered from crtc_state, which we pass around
correctly now even in case of plane disable.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h
On 10/10/2016 15:31, Goel, Akash wrote:
On 10/10/2016 7:22 PM, Tvrtko Ursulin wrote:
On 10/10/2016 11:59, akash.g...@intel.com wrote:
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware
logs and
then dump them to file.
The logs are pulled from a debugfs fi
== Series Details ==
Series: drm/i915: GMBUS don't need no forcewake
URL : https://patchwork.freedesktop.org/series/13641/
State : warning
== Summary ==
Series 13641v1 drm/i915: GMBUS don't need no forcewake
https://patchwork.freedesktop.org/api/1.0/series/13641/revisions/1/mbox/
Test drv_mod
On Wed, Oct 12, 2016 at 02:33:11PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We occasionally depend on eg. to_intel_crtc(NULL) being NULL as
> well. Sprinkle in some BUILD_BUG_ON()s to make sure we don't
> accidentally change things in a way that would violate this
> a
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use fence_write() from rpm
resume
URL : https://patchwork.freedesktop.org/series/13642/
State : failure
== Summary ==
Series 13642v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/13642/revision
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter
from pte_encode
URL : https://patchwork.freedesktop.org/series/13646/
State : failure
== Summary ==
LD fs/btrfs/built-in.o
LD arch/x86/kernel/cpu/built-in.o
LD arch/x86/ke
On Wed, 12 Oct 2016, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> start.
>
> That would be between v4.7 and v4.8. (I guess my report was ambiguous.)
>
> That might take some time. Because
Currently resuming on HSW from S3 pm_test/devices state leads to an
unrecoverable GPU hang. Resetting the GPU during suspend fixes this. For
a full S3 cycle this change only means the reset happens earlier (before
reaching S3). For S4 the reset will happen now both during the freeze
and quiesce pha
On Wed, 2016-10-12 at 17:34 +0300, Jani Nikula wrote:
> In the mean time, please file a bug over at [1] so we don't lose
> track.
Done: https://bugs.freedesktop.org/show_bug.cgi?id=98214
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskto
When execbuf2 supports explicit fencing with sync_file in/out fences
(via a fence-fd), we can control execution via the fence.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/gem_exec_fence.c | 377 +
2 files changed, 378 inse
Rather than guestimating a workload that should take a certain amount of
time, use a sigitimer to terminate a batch (and so complete the wait)
after an exact amount of time. And in the process expand testing to
cover multiple rings and hangcheck.
Signed-off-by: Chris Wilson
---
lib/igt_core.h
On Wed, Oct 12, 2016 at 05:46:37PM +0300, Imre Deak wrote:
> Currently resuming on HSW from S3 pm_test/devices state leads to an
> unrecoverable GPU hang. Resetting the GPU during suspend fixes this. For
> a full S3 cycle this change only means the reset happens earlier (before
> reaching S3). For
1 - 100 of 158 matches
Mail list logo
