在 2024-06-17星期一的 16:42 +0200，Christian König写道：Am 17.06.24 um 16:30 schrieb Icenowy Zheng:在 2024-06-17星期一的 15:59 +0200，Christian König写道：Am 17.06.24 um 15:43 schrieb Icenowy Zheng:在 2024-06-17星期一的 15:09 +0200，Christian König写道：...In this case shouldn't we write seq-1 before any work, and then write seq after work, like what is done in Mesa?No. This hw workaround requires that two consecutive write operations happen directly behind each other on the PCIe bus with two different values.Well to be honest the workaround code in Mesa seems to not be working in this way ...Mesa doesn't have any workaround for that hw issue, the code there uses a quite different approach.Ah? Commit bf26da927a1c ("drm/amdgpu: add cache flush workaround to gfx8 emit_fence") says "Both PAL and Mesa use it for gfx8 too, so port this commit to gfx_v8_0_ring_emit_fence_gfx", so maybe the workaround should just be not necessary here?
What I meant was that Mesa doesn't have a hack like writing seq - 1 and then seq.
I haven't checked the code, but it uses a different approach with 64bit values as far as I know.
To make the software logic around that work without any changes we use the values seq - 1 and seq because those are guaranteed to be different and not trigger any unwanted software behavior. Only then we can guarantee that we have a coherent view of system memory.Any more details about it?No, sorry. All I know is that it's a bug in the cache flush logic which can be worked around by issuing two write behind each other to the same location.So the issue is that the first EOP write does not properly flush the cache? Could EVENT_WRITE be used instead of EVENT_WRITE_EOP in this workaround to properly flush it without hurting the fence value?
No, EVENT_WRITE is executed at a different time in the pipeline.
...Well to be honest on a platform where even two consecutive writes to the same location doesn't work I would have strong doubts that it is stable in general.Well I think the current situation is that the IRQ triggered by the second EOP packet arrives before the second write is finished, not the second write is totally dropped.
Well that sounds like the usual re-ordering problems we have seen patches for on Loongson multiple times now.
And I can only repeat what I've wrote before: We don't accept workarounds in drivers for problems cause by severely platform issues.
Especially when that is clearly against any PCIe specification.
Regards,
Christian.
Regards, Christian.
