[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bcc3325c-ff04-431e-1c72-f4dab957b5a3@redhat.com>
Date: Thu, 20 Jul 2023 23:48:53 +0200
From: Danilo Krummrich <dakr@...hat.com>
To: Steven Price <steven.price@....com>
Cc: airlied@...il.com, daniel@...ll.ch, tzimmermann@...e.de,
mripard@...nel.org, corbet@....net, christian.koenig@....com,
bskeggs@...hat.com, Liam.Howlett@...cle.com,
matthew.brost@...el.com, boris.brezillon@...labora.com,
alexdeucher@...il.com, ogabbay@...nel.org, bagasdotme@...il.com,
willy@...radead.org, jason@...kstrand.net,
donald.robson@...tec.com,
Thomas Hellström
<thomas.hellstrom@...ux.intel.com>, linux-doc@...r.kernel.org,
nouveau@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH drm-misc-next v8 01/12] drm: manager to keep track of GPUs
VA mappings
On 7/20/23 12:44, Steven Price wrote:
> On 20/07/2023 01:14, Danilo Krummrich wrote:
>> Add infrastructure to keep track of GPU virtual address (VA) mappings
>> with a decicated VA space manager implementation.
>>
>> New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
>> start implementing, allow userspace applications to request multiple and
>> arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is
>> intended to serve the following purposes in this context.
>>
>> 1) Provide infrastructure to track GPU VA allocations and mappings,
>> making using an interval tree (RB-tree).
>>
>> 2) Generically connect GPU VA mappings to their backing buffers, in
>> particular DRM GEM objects.
>>
>> 3) Provide a common implementation to perform more complex mapping
>> operations on the GPU VA space. In particular splitting and merging
>> of GPU VA mappings, e.g. for intersecting mapping requests or partial
>> unmap requests.
>>
>> Acked-by: Thomas Hellström <thomas.hellstrom@...ux.intel.com>
>> Acked-by: Matthew Brost <matthew.brost@...el.com>
>> Reviewed-by: Boris Brezillon <boris.brezillon@...labora.com>
>> Tested-by: Matthew Brost <matthew.brost@...el.com>
>> Tested-by: Donald Robson <donald.robson@...tec.com>
>> Suggested-by: Dave Airlie <airlied@...hat.com>
>> Signed-off-by: Danilo Krummrich <dakr@...hat.com>
>
> [...]
>
>> diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c
>> new file mode 100644
>> index 000000000000..dee2235530d6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_gpuva_mgr.c
>
> [...]
>
>> +static bool
>> +drm_gpuva_check_overflow(u64 addr, u64 range)
>> +{
>> + u64 end;
>> +
>> + return WARN(check_add_overflow(addr, range, &end),
>> + "GPUVA address limited to %lu bytes.\n", sizeof(end));
>> +}
>
> This produces a warning on 32 bit systems as sizeof() isn't necessarily
> an unsigned long. The fix below silences the warning.
Thank you for fixing this up! Applied both of your patches to drm-misc-next.
- Danilo
>
> Thanks,
>
> Steve
>
> ---8<-----
> From 9c7356580362b6ac4673724f18ea6e8453b52913 Mon Sep 17 00:00:00 2001
> From: Steven Price <steven.price@....com>
> Date: Thu, 20 Jul 2023 10:58:09 +0100
> Subject: [PATCH] drm: manager: Fix printk format for size_t
>
> sizeof() returns a size_t which may be different to an unsigned long.
> Use the correct format specifier of '%zu' to prevent compiler warnings.
>
> Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
> Signed-off-by: Steven Price <steven.price@....com>
> ---
> drivers/gpu/drm/drm_gpuva_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c
> index 0b80177592a6..f86bfad74ff8 100644
> --- a/drivers/gpu/drm/drm_gpuva_mgr.c
> +++ b/drivers/gpu/drm/drm_gpuva_mgr.c
> @@ -619,7 +619,7 @@ drm_gpuva_check_overflow(u64 addr, u64 range)
> u64 end;
>
> return WARN(check_add_overflow(addr, range, &end),
> - "GPUVA address limited to %lu bytes.\n", sizeof(end));
> + "GPUVA address limited to %zu bytes.\n", sizeof(end));
> }
>
> static bool
Powered by blists - more mailing lists