On Wed, 16 Dec 2020 22:19:11 +0800, Christian König wrote: > > 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. If __memset is supposed to work on those adresses, why this commit(https://github.com/torvalds/linux/commit/ba0b2275a6781b2f3919d931d63329b5548f6d5f) is needed? (I also notice drm/radeon didn't take this change though) just out of curiosity. > > 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. I cannot see what's the more general problem here :( u mean performance? > >> 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. IIUC, e8860 can use amdgpu(I use radeon now) beause its device id 6822 is in amdgpu's table. But I cannot tell whether e8860 has iommu, and I cannot find iommu from lspci, so graphics translation table may not work here? > > >> 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. Thanks! Can you provid some details about these hacks? Should I post another issue on the mail list? _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
