Am 16.12.20 um 14:48 schrieb Chen Li:
On Wed, 16 Dec 2020 15:59:37 +0800,
Christian König wrote:
Am 16.12.20 um 06:41 schrieb Chen Li:
When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon:
[SNIP]
Obviously, the __memset call is generated by gcc(8.3.1). It optimizes
this for loop into memset. But this may break, because dest here is
cpu_addr mapped to io mem. So, just invoke `memset_io` directly, which
do solve the problem here.
Well interesting problem you stumbled over here, but the solution is quite a
hack.
Hi, Christian. I'm not sure why this change is a hack here. I cannot see the problem and wll be grateful if you give more explainations.
__memset is supposed to work on those addresses, otherwise you can't use
the e8860 on your arm64 system.
Replacing the the direct write in the kernel with calls to writel() or
memset_io() will fix that temporary, but you have a more general problem
here.
For amdgpu I suggest that we allocate the UVD message in GTT instead of VRAM
since we don't have the hardware restriction for that on the new generations.
Thanks, I will try to dig into deeper. But what's the "hardware restriction" meaning here? I'm not familiar with video driver stack and amd gpu, sorry.
On older hardware (AGP days) the buffer had to be in VRAM (MMIO) memory,
but on modern system GTT (system memory) works as well.
For radeon I think the better approach would be to convert the direct memory
writes into calls to writel().
Ok, so you mean the more proper way is to use writel instead of memset_io?
Well, it is a start. But I'm not sure if you will ever get that hardware
working with this CPU.
BTW: How does userspace work on arm64 then? The driver stack usually only works
if mmio can be mapped directly.
I also post two usespace issue on mesa, and you may be interested with them:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3954&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RDESyzYBB3ql2GgBigsYf%2Fx2g6zwCq%2Fy8HQ0AAMtX90%3D&reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3951&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y5f9Ki%2FQ8G4zn3MjLVG7yiLLCxbhTyNelZj36hAuXQY%3D&reserved=0
I paste some virtual memory map in userspace there. (and the two problems do bother me quite a long time.)
I don't really see a solution for those problems.
See it is perfectly valid for an application to memset/memcpy on mmaped
MMIO space which comes from OpenGL or Vulkan.
So your CPU simply won't work with the hardware. We could work around
that with a couple of hacks, but this is a pretty much general problem.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
