On Fri, Dec 16, 2016 at 06:31:46PM +, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> >Sent: Friday, December 16, 2016 8:31 AM
> >To: Hiler, Arkadiusz
> >Cc: Srivatsa, Anusha ; intel-
> >g...@lists.freedesktop.org
> >Subject
Hi Chris,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9 next-20161216]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/lib-Add-a-simple-prime-number
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Friday, December 16, 2016 10:47 AM
>To: Srivatsa, Anusha
>Cc: Hiler, Arkadiusz ;
>intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to
>getparams
>
>O
On Fri, Dec 16, 2016 at 03:21:45AM -0500, Robert Foss wrote:
On 2016-12-14 11:13 AM, Brian Starkey wrote:
Hi,
On Wed, Dec 14, 2016 at 04:05:04AM -0500, Robert Foss wrote:
From: Gustavo Padovan
Add support for the OUT_FENCE_PTR property to enable setting out
fences for
atomic commits.
Sign
On Fri, Dec 16, 2016 at 03:35:36AM -0500, Robert Foss wrote:
On 2016-12-14 11:39 AM, Brian Starkey wrote:
Hi,
On Wed, Dec 14, 2016 at 04:05:05AM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
tests/kms_atomic.c | 186
On Fri, Dec 16, 2016 at 03:59:00AM -0500, Robert Foss wrote:
On 2016-12-14 11:57 AM, Brian Starkey wrote:
On Wed, Dec 14, 2016 at 04:05:07AM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 22 +++
With a lot of polish applied, Joonas has reviewed the series - all but
for [04/38] "lib: Add a simple prime number generator"
[lib/prime_numbers.c]. Anyone feel like poking around at a bit of number
theory?
Other than it would appear to be ready for Daniel to sort out the merge
between drm-misc/i9
Acknowledging that we were building up the hole was more useful to me
when reading the code, than knowing the relationship between this node
and the previous node.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 inse
Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and
validation checking using BUG_ON. Ideally these paths should all be
exercised by CI selftests (with the asserts enabled).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 45 +
Simple test to just exercise calling the debug dumper on the drm_mm.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 35
2 files changed, 36 insertions(+
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
v2: Pull together the 3 identical implements (ahem, a coup
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 100 +
When testing, we want a random but yet reproducible order in which to
process elements. Here we create an array which is a random (using the
Tausworthe PRNG) permutation of the order in which to execute.
Note these are simple helpers intended to be merged upstream in lib/
v2: Tidier code by David
First we introduce a smattering of infrastructure for writing selftests.
The idea is that we have a test module that exercises a particular
portion of the exported API, and that module provides a set of tests
that can either be run as an ensemble via kselftest or individually via
an igt harness (in
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
v2: Extract helpers for the repeated tests
v3: Iterate over all allocation flags
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/d
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
"Enable debug, become developer." - Joonas Lahtinen
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
Reuse drm_mm_insert_node() with a temporary node to exercise
drm_mm_replace_node(). We use the previous test in order to exercise the
various lists following replacement.
v2: Check that we copy across the important (user) details of the node.
The internal details (such as lists and hole tracking)
Fairly commonly we want to inspect the node list on the struct drm_mm,
which is buried within an embedded node. Bring it to the surface with a
bit of syntatic sugar.
Note this was intended to be split from commit ad579002c8ec ("drm: Add
drm_mm_for_each_node_safe()") before being applied, but my ti
The nodes must be removed in the *reverse* order. This is correct in the
overview, but backwards in the function description. Whilst here add
Intel's copyright statement and tweak some formatting.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 34 +++
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
Signed-off-by: C
Insulate users from changed to the internal hole tracking within
struct drm_mm_node by using an accessor for hole_follows.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 12 ++--
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
d
Remove a superfluous helper as drm_mm_insert_node is equivalent to
insert_node_in_range with a range of (0, U64_MAX).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 166 ---
include/drm/drm_mm.h | 90 +
Check that after applying the driver's color adjustment, eviction
scanning find a suitable hole.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 156 +++
2 f
For power-of-two alignments, we can avoid the 64bit divide and do a
simple bitwise add instead.
v2: s/alignment_mask/remainder_mask/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 1 +
2 files changed, 9 insertion
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
v2: Refactor out some common eviction code for later
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
d
Check that we add arbitrary blocks to a restrited eviction scanner in
order to find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c |
Check that after applying the driver's color adjustment, restricted
eviction scanning find a suitable hole.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 116 +
Check that we can request alignment to any power-of-two or prime using a
plain drm_mm_node_insert(), and also handle a reasonable selection of
primes.
v2: Exercise all allocation flags
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h |
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/align64
Testcase: igt/gem_exec_alignment
Signed-of
Using mm->color_adjust makes the eviction scanner much tricker since we
don't know the actual neighbours of the target hole until after it is
created (after scanning is complete). To work out whether we need to
evict the neighbours because they impact upon the hole, we have to then
check the hole a
The range restriction should be applied after the color adjustment, or
else we may inadvertently apply the color adjustment to the restricted
hole (and not against its neighbours).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 114 +++
2 files changed, 115 insertions(
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 119 +
mm->color_adjust() compares the hole with its neighbouring nodes. They
only abutt before we restrict the hole, so we have to apply color_adjust
before we apply the range restriction.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 16 ++--
1 f
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
v2: Use all allocation flags
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 264 +
Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
after drm_mm_scan_add_block() we can further simplify the list
manipulations when generating the temporary scan-hole.
v2: Highlight the games being played with the lists to track the scan
holes without allocation.
Signed-off-by
The scan state occupies a large proportion of the struct drm_mm and is
rarely used and only contains temporary state. That makes it suitable to
moving to its struct and onto the stack of the callers.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c
Compute the minimal required hole during scan and only evict those nodes
that overlap. This enables us to reduce the number of nodes we need to
evict to the bare minimum.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c| 60 ++
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
i
Since commit ea7b1dd44867 ("drm: mm: track free areas implicitly"),
to test whether there are any nodes allocated within the range manager,
we merely have to ask whether the node_list is empty.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 19 +-
A simple assert to ensure that we don't overflow start + size when
initialising the drm_mm, or its scanner.
In future, we may want to switch to tracking the value of ranges (rather
than size) so that we can cover the full u64, for example like resource
tracking.
Signed-off-by: Chris Wilson
Revie
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
v2: s/no_color_touching/separate_adjacent_colors/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm
Protect ourselves from a caller passing in node.start + node.size that
will overflow and trick us into reserving that node.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
v2: Check for invalid node reservation.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1
On Fri, Dec 16, 2016 at 07:25:16PM +, Chris Wilson wrote:
> +static void __exit primes_exit(void)
> +{
> + const struct primes *p;
> +
> + mutex_lock(&lock);
> + p = rcu_dereference_protected(primes, lockdep_is_held(&lock));
> + if (p != &small_primes) {
> + kfree_rc
From: Arun Siluvery
In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_pa
From: Arun Siluvery
This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_params.c | 4 +
These patches are to add engine reset feature from Gen8. This is also
referred to as Timeout detection and recovery (TDR). This complements to
the full gpu reset feature available in i915 but it only allows to reset a
particular engine instead of all engines thus providing a light weight
engine res
And before the function description.
Tidy up from commit 14bb2c11796d70b ("drm/i915: Fix a buch of kerneldoc
warnings"), all others kerneldoc blocks look ok.
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
From: Arun Siluvery
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluv
From: Arun Siluvery
A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they are expected to trigger reset; these counts are checked before
and after the test to ensure the same.
Cc: Chris Wilson
Cc:
From: Mika Kuoppala
To perform engine reset we first disable engine to capture its state. This
is done by issuing a reset request. Because we are reusing existing
infrastructure, again when we actually reset an engine, reset function
checks engine mask and issues reset request again which is unne
== Series Details ==
Series: series starting with [v3,01/38] drm/i915: Use the MRU stack search
after evicting
URL : https://patchwork.freedesktop.org/series/16934/
State : warning
== Summary ==
Series 16934v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16934/
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.
To start the discussion, include just a total engine reset count. If it
From: Arun Siluvery
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.
Hangchecker determines which engines a
From: Arun Siluvery
This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at
Since we're not modifying these anywhere, let's make them const so as to
not break code doing comparisons against compile-time CRCs.
Signed-off-by: Lyude
---
lib/igt_debugfs.c | 2 +-
lib/igt_debugfs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/igt_debugfs.c b/lib
On Fri, Dec 16, 2016 at 12:20:07PM -0800, Michel Thierry wrote:
> From: Arun Siluvery
>
> Driver maintains count of how many times a given engine is reset, useful to
> capture this in error state also. It gives an idea of how engine is coping
> up with the workloads it is executing before this er
On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:
> From: Arun Siluvery
>
> This change implements support for per-engine reset as an initial, less
> intrusive hang recovery option to be attempted before falling back to the
> legacy full GPU reset recovery mode if necessary. This is
== Series Details ==
Series: Execlist based engine-reset
URL : https://patchwork.freedesktop.org/series/16936/
State : warning
== Summary ==
Series 16936v1 Execlist based engine-reset
https://patchwork.freedesktop.org/api/1.0/series/16936/revisions/1/mbox/
Test kms_pipe_crc_basic:
Sub
On 16/12/16 12:37, Chris Wilson wrote:
On Fri, Dec 16, 2016 at 12:20:07PM -0800, Michel Thierry wrote:
From: Arun Siluvery
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloa
On Tue, Dec 13, 2016 at 09:15:35PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/4] drm/i915: introduce GEM_WARN_ON
> URL : https://patchwork.freedesktop.org/series/16758/
> State : success
>
> == Summary ==
>
> Series 16758v1 Series without cover letter
>
On Fri, Dec 16, 2016 at 12:20:02PM -0800, Michel Thierry wrote:
> And before the function description.
> Tidy up from commit 14bb2c11796d70b ("drm/i915: Fix a buch of kerneldoc
> warnings"), all others kerneldoc blocks look ok.
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Michel Thierry
Reviewed-by:
On Wed, Dec 07, 2016 at 02:04:52PM -0800, Manasi Navare wrote:
> This is the userspace component of the Displayport Compliance
> testing software required for compliance testing of the I915
> Display Port driver. This must be running in order to successfully
> complete Display Port compliance testi
On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> On Fri, 16 Dec 2016, Daniel Vetter wrote:
> > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> >> The two remaining patches from [1], rebased.
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> [1]
> >> 1480984058-552-1-git-send-email-
101 - 166 of 166 matches
Mail list logo
