[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <0c6127da-53d8-4c37-8337-e64e3e91bbaf@app.fastmail.com>
Date: Wed, 28 Feb 2024 13:26:29 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Lucas De Marchi" <lucas.demarchi@...el.com>,
"Arnd Bergmann" <arnd@...nel.org>
Cc: "Oded Gabbay" <ogabbay@...nel.org>,
Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
"Maxime Ripard" <mripard@...nel.org>,
"Thomas Zimmermann" <tzimmermann@...e.de>, "Dave Airlie" <airlied@...il.com>,
"Daniel Vetter" <daniel@...ll.ch>, "Rodrigo Vivi" <rodrigo.vivi@...el.com>,
"Matt Roper" <matthew.d.roper@...el.com>,
"Matthew Brost" <matthew.brost@...el.com>, intel-xe@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] [v2] drm/xe/xe2: fix 64-bit division in pte_update_size
On Mon, Feb 26, 2024, at 17:40, Lucas De Marchi wrote:
> On Mon, Feb 26, 2024 at 01:46:38PM +0100, Arnd Bergmann wrote:
>>
>>Fixes: 237412e45390 ("drm/xe: Enable 32bits build")
>>Signed-off-by: Arnd Bergmann <arnd@...db.de>
>>---
>>v2: use correct Fixes tag
>
> but what about the other comment? How are we supposed to use
> DIV_ROUND_UP() but then in some places (which?) have to open code it?
The problem is not DIV_ROUND_UP() but the division but the 64-bit
division itself. There is a DIV_ROUND_UP_ULL() macro that would
address the build failure as well, but doing the shift is much
more efficient here since it can be done in a couple of instructions.
> What compiler does this fail on?
I saw it with clang-19 on 32-bit arm, but I assume it happens
on others as well.
>> drivers/gpu/drm/xe/xe_migrate.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
>>index a66fdf2d2991..ee1bb938c493 100644
>>--- a/drivers/gpu/drm/xe/xe_migrate.c
>>+++ b/drivers/gpu/drm/xe/xe_migrate.c
>>@@ -462,7 +462,7 @@ static u32 pte_update_size(struct xe_migrate *m,
>> } else {
>> /* Clip L0 to available size */
>> u64 size = min(*L0, (u64)avail_pts * SZ_2M);
>>- u64 num_4k_pages = DIV_ROUND_UP(size, XE_PAGE_SIZE);
>>+ u32 num_4k_pages = (size + XE_PAGE_SIZE - 1) >> XE_PTE_SHIFT;
>
> also the commit message doesn't seem to match the patch as you are only
> changing one instance.
Not sure what you mean. As I wrote in the changelog, the
second instance is fixed by using a 32-bit division here,
which does not cause link failures.
Arnd
Powered by blists - more mailing lists