From: "Christian König" <christian.koenig@amd.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
airlied@gmail.com, daniel@ffwll.ch, lucas.demarchi@intel.com,
rodrigo.vivi@intel.com, jani.nikula@linux.intel.com,
ray.huang@amd.com, kraxel@redhat.com, airlied@redhat.com,
suijingfeng@loongson.cn
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/6] drm/ttm: Store the bo_kmap_type in struct iosys_map
Date: Fri, 14 Jun 2024 16:31:56 +0200 [thread overview]
Message-ID: <5e770114-2751-414f-af57-de8077f6a6a0@amd.com> (raw)
In-Reply-To: <20240614133556.11378-3-tzimmermann@suse.de>
Am 14.06.24 um 15:21 schrieb Thomas Zimmermann:
> For each instances of struct iosys_map set up by ttm_bo_vmap(), store
> the type of allocation in the instance. Use this information to unmap
> the memory in ttm_bo_vunmap(). This change simplifies the unmap code
> and puts the complicated logic entirely into the map code.
I'm not sure that's a good idea.
The mapping information should already be available in the resource and
storing it in the iosys_map structures duplicates that information.
So we might run into the issue that the resource has changed and so we
need a different approach now, but the iosys_map will say that we should
unmap things for example.
Regards,
Christian.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 46 +++++++++++++++++++++----------
> 1 file changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 0b3f4267130c4..a9df0deff2deb 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -36,6 +36,7 @@
> #include <drm/ttm/ttm_tt.h>
>
> #include <drm/drm_cache.h>
> +#include <drm/drm_device.h>
>
> struct ttm_transfer_obj {
> struct ttm_buffer_object base;
> @@ -479,24 +480,29 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct iosys_map *map)
>
> if (mem->bus.is_iomem) {
> void __iomem *vaddr_iomem;
> + u16 alloc_flags;
>
> - if (mem->bus.addr)
> + if (mem->bus.addr) {
> vaddr_iomem = (void __iomem *)mem->bus.addr;
> - else if (mem->bus.caching == ttm_write_combined)
> - vaddr_iomem = ioremap_wc(mem->bus.offset,
> - bo->base.size);
> + alloc_flags = ttm_bo_map_premapped;
> + } else if (mem->bus.caching == ttm_write_combined) {
> + vaddr_iomem = ioremap_wc(mem->bus.offset, bo->base.size);
> + alloc_flags = ttm_bo_map_iomap;
> #ifdef CONFIG_X86
> - else if (mem->bus.caching == ttm_cached)
> - vaddr_iomem = ioremap_cache(mem->bus.offset,
> - bo->base.size);
> + } else if (mem->bus.caching == ttm_cached) {
> + vaddr_iomem = ioremap_cache(mem->bus.offset, bo->base.size);
> + alloc_flags = ttm_bo_map_iomap;
> #endif
> - else
> + } else {
> vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
> + alloc_flags = ttm_bo_map_iomap;
> + }
>
> if (!vaddr_iomem)
> return -ENOMEM;
>
> iosys_map_set_vaddr_iomem(map, vaddr_iomem);
> + map->alloc_flags = alloc_flags;
>
> } else {
> struct ttm_operation_ctx ctx = {
> @@ -506,6 +512,7 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct iosys_map *map)
> struct ttm_tt *ttm = bo->ttm;
> pgprot_t prot;
> void *vaddr;
> + u16 alloc_flags;
>
> ret = ttm_tt_populate(bo->bdev, ttm, &ctx);
> if (ret)
> @@ -519,8 +526,10 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct iosys_map *map)
> vaddr = vmap(ttm->pages, ttm->num_pages, 0, prot);
> if (!vaddr)
> return -ENOMEM;
> + alloc_flags = ttm_bo_map_vmap;
>
> iosys_map_set_vaddr(map, vaddr);
> + map->alloc_flags = alloc_flags;
> }
>
> return 0;
> @@ -537,20 +546,27 @@ EXPORT_SYMBOL(ttm_bo_vmap);
> */
> void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct iosys_map *map)
> {
> - struct ttm_resource *mem = bo->resource;
> -
> dma_resv_assert_held(bo->base.resv);
>
> if (iosys_map_is_null(map))
> return;
>
> - if (!map->is_iomem)
> - vunmap(map->vaddr);
> - else if (!mem->bus.addr)
> + switch (map->alloc_flags) {
> + case ttm_bo_map_iomap:
> iounmap(map->vaddr_iomem);
> - iosys_map_clear(map);
> -
> + break;
> + case ttm_bo_map_vmap:
> + vunmap(map->vaddr);
> + break;
> + case ttm_bo_map_premapped:
> + break;
> + default:
> + drm_err(bo->base.dev, "Unsupported alloc_flags 0x%x\n", map->alloc_flags);
> + return;
> + }
> ttm_mem_io_free(bo->bdev, bo->resource);
> +
> + iosys_map_clear(map);
> }
> EXPORT_SYMBOL(ttm_bo_vunmap);
>
next prev parent reply other threads:[~2024-06-14 14:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 13:21 [PATCH 0/6] drm/{ttm,xe}: Improve ttm_bo_vmap() and update xe Thomas Zimmermann
2024-06-14 13:21 ` [PATCH 1/6] iosys-map: Add allocator flags Thomas Zimmermann
2024-06-14 13:21 ` [PATCH 2/6] drm/ttm: Store the bo_kmap_type in struct iosys_map Thomas Zimmermann
2024-06-14 14:31 ` Christian König [this message]
2024-06-17 12:32 ` Thomas Zimmermann
2024-06-17 12:56 ` Christian König
2024-06-14 13:21 ` [PATCH 3/6] drm/ttm: Support partial buffer mappings for ttm_bo_vmap() Thomas Zimmermann
2024-06-14 14:33 ` Christian König
2024-06-17 13:00 ` Thomas Zimmermann
2024-06-14 13:21 ` [PATCH 4/6] drm/ttm: Support kmap for single-page mappings in ttm_bo_vmap() Thomas Zimmermann
2024-06-14 13:21 ` [PATCH 5/6] drm/xe: Remove vunmap calls object-freeing code Thomas Zimmermann
2024-06-14 13:22 ` [PATCH 6/6] drm/xe: Replace ttm_bo_kmap() with ttm_bo_vmap() Thomas Zimmermann
2024-06-14 13:41 ` ✓ CI.Patch_applied: success for drm/{ttm,xe}: Improve ttm_bo_vmap() and update xe Patchwork
2024-06-14 13:41 ` ✗ CI.checkpatch: warning " Patchwork
2024-06-14 13:42 ` ✓ CI.KUnit: success " Patchwork
2024-06-14 13:54 ` ✓ CI.Build: " Patchwork
2024-06-14 13:56 ` ✗ CI.Hooks: failure " Patchwork
2024-06-14 13:58 ` ✗ CI.checksparse: warning " Patchwork
2024-06-14 14:18 ` ✗ Fi.CI.CHECKPATCH: " Patchwork
2024-06-14 14:18 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-06-14 14:28 ` ✗ CI.BAT: failure " Patchwork
2024-06-14 14:32 ` ✓ Fi.CI.BAT: success " Patchwork
2024-06-16 21:28 ` ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e770114-2751-414f-af57-de8077f6a6a0@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=kraxel@redhat.com \
--cc=lucas.demarchi@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=rodrigo.vivi@intel.com \
--cc=suijingfeng@loongson.cn \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.