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@xxxxxxx> 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/
