<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 17.06.24 um 16:57 schrieb Icenowy Zheng: <blockquote type="cite" cite="mid:977af3daf5f7eb048eed0310bc93a321728b6106.camel@icenowy.me"> <pre class="moz-quote-pre" wrap="">在 2024-06-17星期一的 16:42 +0200，Christian König写道： </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Am 17.06.24 um 16:30 schrieb Icenowy Zheng: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">在 2024-06-17星期一的 15:59 +0200，Christian König写道： </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Am 17.06.24 um 15:43 schrieb Icenowy Zheng: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">在 2024-06-17星期一的 15:09 +0200，Christian König写道： </pre> <blockquote type="cite">... </blockquote> <pre class="moz-quote-pre" wrap="">In this case shouldn't we write seq-1 before any work, and then write seq after work, like what is done in Mesa? </pre> </blockquote> <pre class="moz-quote-pre" wrap="">No. This hw workaround requires that two consecutive write operations happen directly behind each other on the PCIe bus with two different values. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Well to be honest the workaround code in Mesa seems to not be working in this way ... </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Mesa doesn't have any workaround for that hw issue, the code there uses a quite different approach. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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?</pre> </blockquote> 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. <blockquote type="cite" cite="mid:977af3daf5f7eb048eed0310bc93a321728b6106.camel@icenowy.me"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Any more details about it? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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?</pre> </blockquote> No, EVENT_WRITE is executed at a different time in the pipeline. <blockquote type="cite" cite="mid:977af3daf5f7eb048eed0310bc93a321728b6106.camel@icenowy.me"> <blockquote type="cite"> <blockquote type="cite">... </blockquote> <pre class="moz-quote-pre" wrap=""> 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. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:977af3daf5f7eb048eed0310bc93a321728b6106.camel@icenowy.me"> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> Regards, Christian. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> </body> </html>