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: Mon, 17 Jun 2024 14:56:17 +0200 [thread overview]
Message-ID: <67be6450-7ae3-4e71-8899-717a023c22dd@amd.com> (raw)
In-Reply-To: <820be6c8-ce77-4262-bb45-2c18597a661d@suse.de>
Hi,
Am 17.06.24 um 14:32 schrieb Thomas Zimmermann:
> Hi
>
> Am 14.06.24 um 16:31 schrieb Christian König:
>> 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.
>
> Patches 1 and 2 are only here to make patch 4 (add the kmap special
> case) work. How can I distinguish between vmap'ed and kmap'ed memory?
> It's not clear to me, whether there is a benefit from patch 4. The xe
> driver makes it sound like that, but the rest of the kernel appears to
> disagree.
Yeah, exactly that's the point.
The last time we talked about that we came to the conclusion that the
kmap approach of mapping only a single page or range of pages isn't that
useful in general.
The only use case where you actually need this is the
ttm_bo_vm_access_kmap() helper and that is static and internal to TTM.
So what exactly is the use case xe tries to handle here?
Regards,
Christian.
>
> Best regards
> Thomas
>
>>
>> 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-17 12:56 UTC|newest]
Thread overview: 19+ 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
2024-06-17 12:32 ` Thomas Zimmermann
2024-06-17 12:56 ` Christian König [this message]
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:28 ` ✗ CI.BAT: 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=67be6450-7ae3-4e71-8899-717a023c22dd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox