On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
Am 04.07.23 um 14:24 schrieb Arnd Bergmann:I'd still like to understand this part better, as we have a lot of
On Tue, Jul 4, 2023, at 08:54, Christian König wrote:Well a bit of both.
Am 03.07.23 um 14:35 schrieb Arnd Bergmann:Not sure I understand the specific requirement. Do you mean the entire
amdgpu driver requires 64-bit BAR addressing, or just the bits that
resize the BARs?
Modern AMD GPUs have 16GiB of local memory (VRAM), making those
accessible to a CPU which can only handle 32bit addresses by resizing
the BAR is impossible to begin with.
But going a step further even without resizing it is pretty hard to get
that hardware working on such an architecture.
arm64 chips with somewhat flawed PCIe implementations, often with
a tiny 64-bit memory space, but otherwise probably capable of
using a GPU.
What exactly do you expect to happen here?
a) Use only part of the VRAM but otherwise work as expected
b) Access all of the VRAM, but at a performance cost for
bank switching?
c) Require kernel changes to make a) or b) work, otherwise
fail to load
d) have no chance of working even with driver changes
Ok, I'll send that as a v2 then.Yes, if that suppresses the warning as well then that makes perfectIt might be cleaner to just not build the whole driver on such systemsHow about this version? This also addresses the build failure, but
or at least leave out this function.
I don't know if this makes any sense:
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
u16 cmd;
int r;
+ if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
+ return 0;
+
sense to me.
Arnd