[PATCH] drm/amdgpu: Use uncached ioremap() for LoongArch

[WANG Xuerui]

On 2023/3/6 10:49, Huacai Chen wrote:
> Hi, Christian,
> 
> On Mon, Mar 6, 2023 at 12:40 AM Christian König
> <christian.koenig at amd.com> wrote:
>>
>> Am 05.03.23 um 06:21 schrieb Huacai Chen:
>>> LoongArch maintains cache coherency in hardware, but its WUC attribute
>>> (Weak-ordered UnCached, which is similar to WC) is out of the scope of
>>> cache coherency machanism. This means WUC can only used for write-only
>>> memory regions. So use uncached ioremap() for LoongArch in the amdgpu
>>> driver.
>>
>> Well NAK. This is leaking platform dependencies into the driver code.
> Then is it acceptable to let ioremap() depend on drm_arch_can_wc_memory()?

Note: he's likely meaning "is it acceptable to use 
drm_arch_can_wc_memory() to decide between ioremap() and ioremap_wc()".

Although I doubt it's acceptable to you (driver) folks either, because 
while drm_arch_can_wc_memory() does isolate platform details from driver 
proper, it's still papering over platform PCIe violation in VRAM domain. 
Still better than having platform defines though.

Also making use of drm_arch_can_wc_memory might fix this fdo issue [1] 
on aarch64 too (where I replied earlier). It seems people simply can't 
stop inventing such micro-architectures sadly...

[1]: https://gitlab.freedesktop.org/drm/amd/-/issues/2313

>>
>> When you have a limitation that ioremap_wc() can't guarantee read/write
>> ordering then that's pretty clearly a platform bug and you would need to
>> apply this workaround to all drivers using ioremap_wc() which isn't
>> really feasible.
>>

I agree in this case perhaps all of ioremap_wc() usages would have to 
degrade into ioremap() for correctness on such platforms. In which case 
amdgpu wouldn't have to be individually called out / touched anyway. 
Whether this is easily doable/upstreamable is another question though...

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/