reintroduced patch that
fixes invalid offsets incorrectly assumed as occupied.
Signed-off-by: Janusz Krzysztofik
Cc: Katarzyna Dec
Cc: Stuart Summers
Reviewed-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Chris), use
object validation library helper just introduced,
- name the variable 'stride', not 'alignment', it better reflects
its purpose (Chris).
Janusz Krzysztofik (4):
lib/i915: Add minimum GTT alignment helper
tests/gem_exec_reloc: Don't filter out invalid addresses
tes
.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Stuart Summers
---
lib/Makefile.sources| 2 +
lib/i915/gem_gtt_topology.c | 118
lib/i915/gem_gtt_topology.h | 36 +++
lib/meson.build | 1 +
4
minimum GTT
alignment of actual backing store the test is running on.
v2: Update helper name, use 'minimum GTT alignment' term across the
change, adjust variable name.
v3: Name the variable 'stride', not 'alignment', it better reflects
its purpose (Chris).
Signed-off-by: Janusz Krzysztofik
validation library helper just introduced.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..e46a4
Hi Vanshi,
On Thursday, October 31, 2019 5:58:31 PM CET Vanshidhar Konda wrote:
> On Thu, Oct 31, 2019 at 04:28:55PM +0100, Janusz Krzysztofik wrote:
> >Some tests assume 4kB offset alignment while using softpin. That
> >assumption may be wrong on future GEM backends with
Hi Jonas,
On Tuesday, November 5, 2019 10:14:20 AM CET Joonas Lahtinen wrote:
> Quoting Janusz Krzysztofik (2019-11-04 19:13:27)
> > Some tests assume 4kB offset alignment while using softpin. That
> > assumption may be wrong on future GEM backends with possibly larger
> &g
Hi,
On Tuesday, November 5, 2019 3:27:55 PM CET Daniel Vetter wrote:
> On Thu, Oct 31, 2019 at 09:29:56AM +0100, Janusz Krzysztofik wrote:
> > We need dmabuf specific pwrite() callback utilizing dma-buf API,
> > otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed
&
the helper, use 'minimum GTT alignment' term across the
change (Chris),
- use error numbers to distinguish between invalid offsets and
addresses occupied by other users, then
- simplify the code (Chris).
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
"tests/gem_exec_reloc: Don't
filter out invalid addresses" with the former not on full PPGTT
requirement for skipping now replaced with error code checking.
Janusz Krzysztofik (4):
tests/gem_exec_reloc: Don't filter out invalid addresses
lib: Add minimum GTT alignment helper
essage on top of the reintroduced patch that
fixes invalid offsets incorrectly assumed as occupied.
Signed-off-by: Janusz Krzysztofik
Cc: Katarzyna Dec
Cc: Stuart Summers
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
minimum GTT
alignment of actual backing store the test is running on.
v2: Update helper name, use 'minimum GTT alignment' term across the
change, adjust variable name.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_ctx_shared.c | 6 --
1 file changed, 4 insertions
nificantly distort the intended
test pattern.
Filter out failing addresses only if not reported as invalid.
v2: Skip unavailable addresses only when not running on full PPGTT.
v3: Replace the not on full PPGTT requirement for skipping with error
code checking.
Signed-off-by: Janusz Krzysztofik
as invalid.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..1d0c791e 100644
--- a/tests/i915/gem_exec_reloc.c
+
due to lack of space for more commands.
> + *
> + * Only reliably possible to be set prior to first use, i.e. during
> + * construction. At any later point, the current execution must be flushed as
> + * the ring can only be changed while the context is idle.
> + *
> + * Only applies to the current set of engine and lost when those engines
> + * are replaced by a new mapping (see I915_CONTEXT_PARAM_ENGINES).
> + *
> + * Must be between 4 - 512 KiB, in intervals of page size [4 KiB].
> + * Default is 16 KiB.
> + */
> +#define I915_CONTEXT_PARAM_RINGSIZE 0xc
I know it looked like that already before, but having other documented flags
separated by blank lines from each other, Is there any reason for not putting
another blank line after the last one?
> /* Must be kept compact -- no holes and well documented */
>
> __u64 value;
>
None of the above comments are essential so with or without them addressed:
Reviewed-by: Janusz Krzysztofik
Thanks,
Janusz
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
escription, they better correspond to the
original commit being fixed as well as the comment proposed by
Chris.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
Cc: Vanshidhar Konda
Cc: Joonas Lahtinen
---
tests/i915/gem_exec_reloc.c | 14 +++---
1 file changed, 11 insert
Hi,
On Monday, November 4, 2019 9:46:28 PM CET Vanshidhar Konda wrote:
> On Mon, Nov 04, 2019 at 06:13:28PM +0100, Janusz Krzysztofik wrote:
> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> >addresses for !ppgtt") introduced filtering of addre
Hi Daniel,
On Tuesday, November 5, 2019 3:27:55 PM CET Daniel Vetter wrote:
> On Thu, Oct 31, 2019 at 09:29:56AM +0100, Janusz Krzysztofik wrote:
> > We need dmabuf specific pwrite() callback utilizing dma-buf API,
> > otherwise GEM_PWRITE IOCTL will no longer work with dma-buf
Hi Stuart,
On Wednesday, November 20, 2019 11:04:59 PM CET Summers, Stuart wrote:
> On Wed, 2019-11-20 at 17:14 +, Summers, Stuart wrote:
> > On Wed, 2019-11-20 at 17:44 +0100, Janusz Krzysztofik wrote:
> > > As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma
.
Suggested-by: Daniel Vetter
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
According to Trybot, these subtests are failing on Sandybridge (Gen6)
and Haswell (G75), can you please advice how those platforms should be
handled?
Thanks,
Janusz
tests/prime_vgem.c | 189
Boolean module parameters are exposed as "Y"/"N" strings, not 0/1.
Make igt_sysfs_get_boolean() helper useful for getting their values.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
lib/igt_sysfs.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(
Messages displayed on SKIPs introduced by commit 92caadb4e551
("tests/prime_vgem: Skip basic-read/write subtests if not supported")
don't inform clearly enough that those SKIPs are expected behavior.
Fix it.
Signed-off-by: Janusz Krzysztofik
Cc: Ewelina Musial
---
tests/prime_
Boolean module parameters are exposed as "Y"/"N" strings, not 0/1.
Make igt_sysfs_get_boolean() helper useful for getting their values.
v2: Use case insensitive string compare and more compact style (Chris)
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chris Wilson
---
I'v
jdeczko
> Cc: Chris Wilson
> Cc: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +++-
> drivers/gpu/drm/i915/gt/intel_lrc.h | 2 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/driver
Two tests - gem_exec_reloc and gem_softpin - define local helpers for
calculation of softpin offset canonical addresses. As more users are
expected, replace those local instances with a single shared one under
lib/.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
lib/igt_x86.c
page size
of actual backing store the test is running on.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_ctx_shared.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
index f7852482
assuming them occupied by other users, or may always
succeed when examining invalid use patterns.
Provide a helper function that detects minimum page size and returns
the size order. Tests may use it to calculate softpin offsets suitable
for actually used backing store.
Signed-off-by: Janusz
- in former patch 2/2, now 3/4, initialize page size order with an
actual minimum returned by the new helper (inspired by Chris),
- add a new fix for gem_ctx_shared test (patch 4/4).
Janusz Krzysztofik (4):
lib/i915: Move redundant local helpers to lib/
lib/i915: Add GEM minimum page s
From: Janusz Krzysztofik
The basic-range subtest assumes 4kB page size while calculating softpin
offsets. On future backends with possibly larger minimum page sizes
a half of calculated offsets to be tested may be incorrectly detected
as occupied by other users and skiped, significantly
* By default, new contexts allow persistence.
> */
> #define I915_CONTEXT_PARAM_PERSISTENCE 0xb
> +
> +/*
> + *
> + * I915_CONTEXT_PARAM_RINGSIZE:
> + *
> + * Sets the size of the ringbuffer to use for logical ring contexts.
> + * Only possible to be set prio
On Friday, October 18, 2019 1:43:32 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Restore full symmetry in i915_driver_modeset_probe/remove
> URL : https://patchwork.freedesktop.org/series/68188/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
>
XME comment
provided by that commit. While being at it, update the name of
function mentioned as calling it out of sequence as that name has been
changed meanwhile by commit 78dae1ac35dd ("drm/i915: Propagate
"_remove" function name suffix down").
Suggested-by: Michal Wajdeczk
On Friday, October 18, 2019 2:13:18 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Restore full symmetry in i915_driver_modeset_probe/remove
> URL : https://patchwork.freedesktop.org/series/68188/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from
Name of the i915 module parameter providing fault injection function is
changing for consistency with a new convention of naming i915 driver
internal functions called from the driver PCI .probe entry point. Adjust
the test to use the new name.
Suggested-by: Joonas Lahtinen
Signed-off-by: Janusz
to correctly support joint testing with a
corresponding kernel driver side patch.
Janusz Krzysztofik (1):
tests/i915_module_load: Use new name of fault injection module
parameter
tests/i915/i915_module_load.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.21.0
ch to
the "probe" nomenclature.
Suggested-by: Joonas Lahtinen
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i91
Suggested-by: Michał Wajdeczko
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c
essage of 2/2, there are no such (Chris),
* add R-b (thanks Chris),
* use correct message ID of (also rerolled) IGT counterpart to be
tested with.
Janusz Krzysztofik (2):
drm/i915: Fix i915_inject_load_error() name to read *_probe_*
drm/i915: Rename "inject_load_failure"
Hi Chris,
On Tuesday, October 29, 2019 1:49:26 PM CET Chris Wilson wrote:
> From: Janusz Krzysztofik
>
> Name of the i915 module parameter providing fault injection function is
> changing for consistency with a new convention of naming i915 driver
> internal functions called from
instead of using a hardcoded value. To avoid
conflicts with addresses occupied by other users, do that only when
running on full PPGTT. Platforms without full PPGTT are not expected
to support backends with minimum batch sizes greater than 4kB.
Signed-off-by: Janusz Krzysztofik
---
tests/i915
From: Janusz Krzysztofik
The basic-range subtest assumes 4kB minimum batch size. On future
backends with possibly bigger minimum batch sizes this subtest will
fail as buffer objects may overlap on softpin. To avoid object
overlapping, softpin offsets need to be calculated with actual minimum
full (non-aliasing) PPGTT, that may result in errors other
than those intended to be skipped over being silently ignored.
Skip over unavailable addresses only when not running on full PPGTT.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 26 ++-
We need dmabuf specific pread() callback utilizing dma-buf API,
otherwise GEM_PREAD IOCTL will no longer work with dma-buf backed
(i.e., PRIME imported) objects on hardware with no mappable aperture.
Signed-off-by: Janusz Krzysztofik
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers
We need dmabuf specific pwrite() callback utilizing dma-buf API,
otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed
(i.e., PRIME imported) objects on hardware with no mappable aperture.
Signed-off-by: Janusz Krzysztofik
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
From: Matthew Auld
Similar to pwrite, we need pread for (better) support of non-GTT
backends.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
Signed-off-by: Janusz Krzysztofik
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 ++
drivers/gpu
From: Janusz Krzysztofik
The basic-range subtest assumes 4kB minimum batch size. On future
backends with possibly bigger minimum batch sizes this subtest will
fail as buffer objects may overlap. To avoid object overlapping,
offsets need to be calculated with actual minimum batch size in mind
, that may result in errors other than those intended
to be skipped over being silently ignored.
Skip over unavailable addresses only when not running on PPGTT.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 26 ++
1 file c
Hi Chris,
On Wednesday, October 23, 2019 11:13:02 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-23 10:07:52)
> > From: Janusz Krzysztofik
> >
> > The basic-range subtest assumes 4kB minimum batch size. On future
> > backends with possibly
On Wednesday, November 20, 2019 4:53:30 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-20 15:49:33)
> > (fixing malformed intel-gfx list address in Cc:)
> >
> > On Wednesday, November 20, 2019 4:36:41 PM CET Chris Wilson wrote:
> > > Quoting Janusz
running on that kind of hardware, just skip
subtests which use those IOCTLs.
Signed-off-by: Janusz Krzysztofik
Cc: Daniel Vetter
Cc: Joonas Lahtinen
---
lib/ioctl_wrappers.c | 2 +-
lib/ioctl_wrappers.h | 1 +
tests/prime_vgem.c | 6 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff
(fixing malformed intel-gfx list address in Cc:)
On Wednesday, November 20, 2019 4:36:41 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-20 15:32:19)
> > As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma-buf
> > objects doesn't make much sense, w
Hi Chris,
On Tuesday, November 26, 2019 3:34:13 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-26 14:25:48)
> > As we've agreed that using GEM_MMAP* IOCTLs on dma-buf objects without
> > a CPU accessible GART is very questionable, we are probably not going
&g
As we've agreed that using GEM_MMAP* IOCTLs on dma-buf objects without
a CPU accessible GART is very questionable, we are probably not going
to extend our MMAP_OFFSET handler with an extra processing path
required for it to work correctly on dma-buf objects. As a
consequence, on future hardware
running on that kind of hardware, just skip
subtests which use those IOCTLs.
v2: Examine pread/pwrite ABI, not mmap ABI (Chris)
Signed-off-by: Janusz Krzysztofik
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
Resubmitting with Joonas' email address in Cc: tag corrected, as well
running on that kind of hardware, just skip
subtests which use those IOCTLs.
v2: Examine pread/pwrite ABI, not mmap ABI (Chris)
v3: Don't use "no mappable GGTT" wording in commit message (Chris)
Signed-off-by: Janusz Krzysztofik
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Reviewed-by: Ch
Please ignore, I didn't notice it has been already merged.
Thanks,
Janusz
On Monday, December 2, 2019 8:53:51 AM CET Janusz Krzysztofik wrote:
> As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma-buf
> objects doesn't make much sense, we are not going to extend their
>
running on that kind of hardware, just skip
subtests which use those IOCTLs.
v2: Examine pread/pwrite ABI, not mmap ABI (Chris)
v3: Don't use "no mappable GGTT" wording in commit message (Chris)
Signed-off-by: Janusz Krzysztofik
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Reviewed-by: Ch
Hi Chris,
I have a few questions rather than comments. I hope they are worth spending
your time.
On Wednesday, November 13, 2019 1:52:40 PM CET Chris Wilson wrote:
> I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command
> ringbuffer for logical ring contects. This directly
Hi Chris,
On Tuesday, November 26, 2019 3:34:13 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-26 14:25:48)
> > As we've agreed that using GEM_MMAP* IOCTLs on dma-buf objects without
> > a CPU accessible GART is very questionable, we are probably not going
&g
On Wednesday, October 30, 2019 10:19:43 PM CET Vanshidhar Konda wrote:
> On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> >addresses for !ppgtt") introduced filtering of addresses poss
We need dmabuf specific pwrite() callback utilizing dma-buf API,
otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed
(i.e., PRIME imported) objects on hardware with no mappable aperture.
Signed-off-by: Janusz Krzysztofik
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
From: Matthew Auld
Similar to pwrite, we need pread for (better) support of non-GTT
backends.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
Signed-off-by: Janusz Krzysztofik
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 ++
drivers/gpu
We need dmabuf specific pread() callback utilizing dma-buf API,
otherwise GEM_PREAD IOCTL will no longer work with dma-buf backed
(i.e., PRIME imported) objects on hardware with no mappable aperture.
Signed-off-by: Janusz Krzysztofik
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers
solves it own distinct issue, that's why I think they
should be kept separate.
Thanks,
Janusz
> Vanshi
>
> On Thu, Oct 31, 2019 at 04:28:54PM +0100, Janusz Krzysztofik wrote:
> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> >addresses for !ppgtt&quo
Hi Chris,
On Friday, November 1, 2019 11:08:45 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-31 15:28:55)
> > Some tests assume 4kB offset alignment while using softpin. That
> > assumption may be wrong on future GEM backends with possibly larger
> &g
Hi Chris,
On Friday, November 1, 2019 10:42:18 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-31 15:28:57)
> > exec-shared-gtt-* subtests use hardcoded values for object size and
> > softpin offset, based on 4kB GTT alignment assumption. That may result
> &
On Monday, November 4, 2019 10:28:37 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-04 09:23:12)
> > Hi Chris,
> >
> > On Friday, November 1, 2019 11:08:45 AM CET Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2019-10-31 15:28:55)
> &
Hi Chris,
On Friday, November 1, 2019 11:02:45 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-31 15:28:54)
> > Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> > addresses for !ppgtt") introduced filtering of addresses possibly
&g
Hi Chris,
On Wednesday, October 2, 2019 6:00:34 PM CEST Chris Wilson wrote:
> If we have a wedged GPU that we need to recover, but fail, add a taint
> for CI to pickup and schedule a reboot.
As your approach has been chosen by CI, FWIW:
Reviewed-by: Janusz Krzysztofik
Thanks,
Hi Baolu,
On Friday, October 11, 2019 8:54:09 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 9/3/19 3:41 PM, Janusz Krzysztofik wrote:
> > Hi Baolu,
> >
> > On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >>
aperture. Use GEM_MMAP_OFFSET
instead and iterate MMAP_OFFSET coherent types to find one that works.
Signed-off-by: Janusz Krzysztofik
Cc: Michał Winiarski
---
Hi Michał,
As you are the author of those subtests, let me ask you a few questions
I'm not sure about:
1. How critical is the use
Hi Chris,
On Tuesday, February 11, 2020 12:39:36 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-04 11:41:13)
> > On future hardware with missing GGTT BAR we won't be able to exercise
> > dma-buf access via that path. An alternative to basic-gtt subtest for
>
Hi Chris,
On Tuesday, February 11, 2020 5:44:59 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> > @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler,
> > NULL)
> > ig
Hi Michał,
On Thursday, February 13, 2020 3:37:31 PM CET Michał Winiarski wrote:
> On Thu, Feb 13, 2020 at 01:46:41PM +0100, Janusz Krzysztofik wrote:
> > map-fixed-invalidate* subtests utilize gem_set_tiling() which may fail,
> > e.g. on hardware with no mappable aperture, due to
, with skips handled at mmap-offset attempt
performed by the test anyway (Chris),
- for better clarity of the patch, drop cosmetic only changes,
- use more concise wording in subtest description.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 43
Hi Chris,
On Fri, 2020-02-21 at 14:28 +, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > Currently unavoidable lockedp loop related to userptr MMU notifier
> > exists in the i915 driver. For that reason, attempts to set up a
> > mmap-offset
mmap
types to GTT if no MMAP_OFFSET support").
Signed-off-by: Janusz Krzysztofik
Cc: Michał Winiarski
---
tests/i915/gem_userptr_blits.c | 43 +++---
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/
Message
From: Patchwork
Reply-To: intel-gfx-try...@lists.freedesktop.org
To: Janusz Krzysztofik
Cc: intel-gfx-try...@lists.freedesktop.org
Subject: ✓ Fi.CI.IGT: success for gem_userptr_blits: Refresh other now
MMAP_GTT dependent subtests
Date: Wed, 04 Mar 2020 11:24:45 -
== Series
Hi,
Here are my comments to CI results from testing the IGT changes on
Trybot with kernel change that prevents non-GTT mmap-offset mapping to
userptr reverted.
On Thu, 2020-03-05 at 06:15 +, Patchwork wrote:
> == Series Details ==
>
> Series: gem_userptr_blits: mmap-offset-invalidate
type if there are any.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 108 -
1 file changed, 79 insertions(+), 29 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index efe34c512..3c659db0c 100644
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests
se" series,
still waiting for someone to provide a review) patches, this series
concludes MMAP_OFFSET related changes required for gem_userptr_blits,
I believe.
Thanks,
Janusz
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
tests/gem_userptr_blits: Refres
It has been observed that mmap-offset-invalidate@wb subtest has never
triggered a lockdep loop complain. To fix it, don't use the ->domain
field of a mapping type being examined, always set read and write
domains to I915_GEM_DOMAIN_GTT instead.
Signed-off-by: Janusz Krzysztofik
---
tests/i
Add a variant that also attaches a igt_spin_t to the userptr, waits for
it to start executing, call igt_spin_set_timeout and then do the munmap.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 33 -
1 file
Janusz Krzysztofik (3):
tests/gem_userptr_blits: More effectively set pages before invalidation
tests/gem_userptr_blits: More exact detection of lockdep loop prevention
tests/gem_userptr_blits: Add active variant of mmap-offset-invalidate
tests/i915/gem_userptr_blits.c | 40
If mmap-offset over userptr fails, skip with respective message about
lockdep loop preventive failure occurrence only if ENODEV, fail
otherwise.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests
actually try to anger lockdep using gem_set_tiling() (Chris).
- rebase on top of "lib/i915: Restrict mmap types to GTT if no
MMAP_OFFSET support".
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Exercise new invalid mapping types
tests/gem_userptr_blits: Try to anger lo
A currently unavoidable lockdep loop related to userptr MMU notifier
exists inside the i915 driver. For as long as that issue is not
resolved, operations which are believed to potentially result in the
loop being triggered are expected to fail early to prevent from that
badness to happen.
The
t; section,
- rebase on top of "lib/i915: Restrict mmap types to GTT if no
MMAP_OFFSET support".
Signed-off-by: Janusz Krzysztofik
Cc: Antonio Argenziano
---
tests/i915/gem_userptr_blits.c | 38 +++---
1 file changed, 21 insertions(+), 17 deletions(-)
Sorry for replying to myself again.
On Wednesday, January 22, 2020 4:24:49 PM CET Janusz Krzysztofik wrote:
> Hi Chris,
>
> On Thursday, January 9, 2020 4:03:30 PM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-01-09 14:01:25)
> > > On future hardware with m
Creating a mapping to a userptr backed GEM object may cause a currently
unavoidable lockdep splat inside the i915 driver. Then, such operation
is expected to fail to prevent from that badness to happen.
Add a respective subtest for each mapping type.
Signed-off-by: Janusz Krzysztofik
Cc
I'm adding a cover letter in case it is required for having a related
kernel side patch been tested with this one. Since I've proposed to
change an error code returned by an IOCTL, this patch is expected to
fail when tested alone, without the kernel side counterpart.
Thanks,
Janusz
Janusz
i915: Introduce DRM_I915_GEM_MMAP_OFFSET"). Those new mapping
types suffer from the same lockdep splat issue but they now succeed
when tried on top of a userptr object. Fix it.
While being at it, return -EINVAL which seems to better reflect the
reason for the failure than -ENODEV.
Signed-off-by: Ja
Test-with: <20200131131234.23058-2-janusz.krzyszto...@linux.intel.com>
As I'm proposing to change an error code returned by an IOCTL, this
patch must be tested with a corresponding patch on the IGT side.
Janusz Krzysztofik (1):
drm/i915: Never allow userptr into the new mapping types
d
On Friday, January 31, 2020 3:32:21 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:20:37)
> > Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
> > mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when atepmted
> &g
On Friday, January 31, 2020 3:37:05 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:12:34)
> > Creating a mapping to a userptr backed GEM object may cause a currently
> > unavoidable lockdep splat inside the i915 driver. Then, such operation
> >
i915: Introduce DRM_I915_GEM_MMAP_OFFSET"). Those new mapping
types suffer from the same lockdep splat issue but they now succeed
when tried on top of a userptr object. Fix it.
v2: Don't play with the -ENODEV driver response (Chris)
Signed-off-by: Janusz Krzysztofik
Cc: Abdiel Janulgue
Cc: Chris
On Friday, January 31, 2020 3:32:21 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:20:37)
> > Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
> > mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when atepmted
> &g
XY_SRC_COPY_BLT helper to match the name of
its library version just merged.
Suggested-by: Chris Wilson
Suggested-by: Daniel Vetter
Reviewed-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
Hi Chris,
I hope I've understood and addressed your comments correctly so your
R-b still applies.
Thanks
Hi Antonio,
On Tuesday, January 28, 2020 1:59:00 AM CET Antonio Argenziano wrote:
>
> On 22/01/20 08:26, Janusz Krzysztofik wrote:
> > Working with a userptr GEM object backed by any type of mapping to
> > another GEM object, not only GTT mapping currently examined bu the
&
101 - 200 of 813 matches
Mail list logo
