[PATCH] drm/[amdgpu|radeon]: fix memset on io mem

[Christian König]

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.