Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On Thu, Sep 24, 2020 at 01:22:35PM +0100, Tvrtko Ursulin wrote: > CI says series looks good from the i915 perspective (*). > > I don't know how will you handle it logistically, but when you have final > version I am happy to re-read and r-b the i915 patches. I'll resend the series later today, and will make sure you are on the Cc list.
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On 23/09/2020 15:44, Christoph Hellwig wrote: On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote: Series did not get a CI run from our side because of a different base so I don't know if you would like to have a run there? If so you would need to rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI. That's fine, just ping me and I will forward it for testing, thanks! git://git.infradead.org/users/hch/misc.git i915-vmap-wip Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-vmap-wip note that this includes a new commit to clean up one of the recent commits in the code. CI says series looks good from the i915 perspective (*). I don't know how will you handle it logistically, but when you have final version I am happy to re-read and r-b the i915 patches. Regards, Tvrtko *) https://patchwork.freedesktop.org/series/82051/
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote: >>> Series did not get a CI run from our side because of a different base so I >>> don't know if you would like to have a run there? If so you would need to >>> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could >>> even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing >>> cc, to check it out without sending a copy to the real mailing list. >> >> It doesn't seem like I can post to any freedesktop list, as I always >> get rejection messages. But I'll happily prepare a branch if one >> of you an feed it into your CI. > > That's fine, just ping me and I will forward it for testing, thanks! git://git.infradead.org/users/hch/misc.git i915-vmap-wip Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-vmap-wip note that this includes a new commit to clean up one of the recent commits in the code.
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On 23/09/2020 14:41, Christoph Hellwig wrote: On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote: On 18/09/2020 17:37, Christoph Hellwig wrote: i915_gem_object_map implements fairly low-level vmap functionality in a driver. Split it into two helpers, one for remapping kernel memory which can use vmap, and one for I/O memory that uses vmap_pfn. The only practical difference is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't seem to be required here for the kernel memory case (and could be added to vmap using a flag if actually required). Patch looks good to me. Series did not get a CI run from our side because of a different base so I don't know if you would like to have a run there? If so you would need to rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI. That's fine, just ping me and I will forward it for testing, thanks! Regards, Tvrtko
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote: > > On 18/09/2020 17:37, Christoph Hellwig wrote: >> i915_gem_object_map implements fairly low-level vmap functionality in >> a driver. Split it into two helpers, one for remapping kernel memory >> which can use vmap, and one for I/O memory that uses vmap_pfn. >> >> The only practical difference is that alloc_vm_area prefeaults the >> vmalloc area PTEs, which doesn't seem to be required here for the >> kernel memory case (and could be added to vmap using a flag if actually >> required). > > Patch looks good to me. > > Series did not get a CI run from our side because of a different base so I > don't know if you would like to have a run there? If so you would need to > rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could > even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing > cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI.
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On 18/09/2020 17:37, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Patch looks good to me.
Series did not get a CI run from our side because of a different base so
I don't know if you would like to have a run there? If so you would need
to rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you
could even send a series to intel-gfx-try...@lists.freedesktop.org,
suppressing cc, to check it out without sending a copy to the real
mailing list.
Regards,
Tvrtko
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 101 ++
2 files changed, 47 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
+ select VMAP_PFN
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index e8a083743e0927..90029ea83aede9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -234,50 +234,24 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
return err;
}
-static inline pte_t iomap_pte(resource_size_t base,
- dma_addr_t offset,
- pgprot_t prot)
-{
- return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
/* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
enum i915_map_type type)
{
- unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
- struct sg_table *sgt = obj->mm.pages;
- pte_t *stack[32], **mem;
- struct vm_struct *area;
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+ struct page *stack[32], **pages = stack, *page;
+ struct sgt_iter iter;
pgprot_t pgprot;
-
- if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
- return NULL;
-
- /* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB)
- return kmap(sg_page(sgt->sgl));
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- /* Too big for stack -- allocate temporary array instead */
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
-
- area = alloc_vm_area(obj->base.size, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
- return NULL;
- }
+ void *vaddr;
switch (type) {
default:
MISSING_CASE(type);
fallthrough;/* to use PAGE_KERNEL anyway */
case I915_MAP_WB:
+ /* A single page can always be kmapped */
+ if (n_pages == 1)
+ return kmap(sg_page(obj->mm.pages->sgl));
pgprot = PAGE_KERNEL;
break;
case I915_MAP_WC:
@@ -285,30 +259,44 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
break;
}
- if (i915_gem_object_has_struct_page(obj)) {
- struct sgt_iter iter;
- struct page *page;
- pte_t **ptes = mem;
-
- for_each_sgt_page(page, iter, sgt)
- **ptes++ = mk_pte(page, pgprot);
- } else {
- resource_size_t iomap;
- struct sgt_iter iter;
- pte_t **ptes = mem;
- dma_addr_t addr;
+ if (n_pages > ARRAY_SIZE(stack)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return NULL;
+ }
- iomap = obj->mm.region->iomap.base;
- iomap -= obj->mm.region->region.start;
+ for_each_sgt_page(page, iter, obj->mm.pages)
+ pages[i++] = page;
+ vaddr = vmap(pages,
