| Message ID | 20201130141809.65330-2-matthew.auld@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] drm/i915/selftest: also consider non-contiguous objects | expand |
Quoting Matthew Auld (2020-11-30 14:18:09) > For the LMEM case if we have suitable alignment and 2M physical pages we > should always get 2M GTT pages within the constraints of the hugepages > selftest. If we don't then something might be wrong in our construction > of the backing pages. > > References: 330b7d33056b ("drm/i915/region: fix order when adding blocks") > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > --- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c > index 0bf93947d89d..cecbd2012e9d 100644 > --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c > +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c > @@ -368,6 +368,25 @@ static int igt_check_page_sizes(struct i915_vma *vma) > err = -EINVAL; > } > > + /* > + * The dma-api is like a box of chocolates when it comes to the > + * alignment of dma addresses, however for LMEM we have total control > + * and so can guarantee alignment, likewise when we allocate our blocks > + * they should appear in descending order, and if we know that we align > + * to the largest page size for the GTT address, we should be able to > + * assert that if we see 2M physical pages then we should also get 2M > + * GTT pages. If we don't then something might be wrong in our > + * construction of the backing pages. 2MiB alignment in the GTT is required to use huge pages on the GPU. My wish would be to somehow extract that info from vm, but if you can include the reason why we are interested in maintaining the 2MiB alignment, then Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c index 0bf93947d89d..cecbd2012e9d 100644 --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c @@ -368,6 +368,25 @@ static int igt_check_page_sizes(struct i915_vma *vma) err = -EINVAL; } + /* + * The dma-api is like a box of chocolates when it comes to the + * alignment of dma addresses, however for LMEM we have total control + * and so can guarantee alignment, likewise when we allocate our blocks + * they should appear in descending order, and if we know that we align + * to the largest page size for the GTT address, we should be able to + * assert that if we see 2M physical pages then we should also get 2M + * GTT pages. If we don't then something might be wrong in our + * construction of the backing pages. + */ + if (i915_gem_object_is_lmem(obj) && + IS_ALIGNED(vma->node.start, SZ_2M) && + vma->page_sizes.sg & SZ_2M && + vma->page_sizes.gtt < SZ_2M) { + pr_err("gtt pages mismatch for LMEM, expected 2M GTT pages, sg(%u), gtt(%u)\n", + vma->page_sizes.sg, vma->page_sizes.gtt); + err = -EINVAL; + } + if (obj->mm.page_sizes.gtt) { pr_err("obj->page_sizes.gtt(%u) should never be set\n", obj->mm.page_sizes.gtt);
For the LMEM case if we have suitable alignment and 2M physical pages we should always get 2M GTT pages within the constraints of the hugepages selftest. If we don't then something might be wrong in our construction of the backing pages. References: 330b7d33056b ("drm/i915/region: fix order when adding blocks") Signed-off-by: Matthew Auld <matthew.auld@intel.com> --- .../gpu/drm/i915/gem/selftests/huge_pages.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)