<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 02.07.24 um 11:06 schrieb Icenowy Zheng: <blockquote type="cite" cite="mid:b9189c97f7efbaa895198113ee5b47012bd8b4dc.camel@icenowy.me">[SNIP] <pre class="moz-quote-pre" wrap="">However I don't think the definition of the AGP spec could apply on all PCI(e) implementations. The AGP spec itself don't apply on implementations that do not implement AGP (which is the most PCI(e) implementations today), and it's not in the reference list of the PCIe spec, so it does no help on this context.</pre> </blockquote> No, exactly that is not correct. See as I explained the No-Snoop extension to PCIe was created to help with AGP support and later merged into the base PCIe specification. So the AGP spec is now part of the PCIe spec. [SNIP] <blockquote type="cite" cite="mid:b9189c97f7efbaa895198113ee5b47012bd8b4dc.camel@icenowy.me"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">We have quite a bunch of V4L, sound and I also think network devices which work like that. But those are non-PCI devices. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I think in the Linux kernel most drivers (of course including PCI ones) use DMA buffer in this way, which makes them natually compatible with non-coherent PCIe implementations. TTM is one of the few exceptions here.</pre> </blockquote> Yes and that is absolutely intentional. See we don't want to support any non-coherent PCIe implementation. [SNIP] <blockquote type="cite" cite="mid:b9189c97f7efbaa895198113ee5b47012bd8b4dc.camel@icenowy.me"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">And if I'm not completely mistaken the RISC-V specification was also updated to disallow stuff like this. So yes you can have boards which implement non-snooped PCIe, but you get exactly zero support from hardware vendors to run software on it. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> It's a quite usual case for free softwares to get no support from hardware vendors, and some of them are even developed by reverse engineering. I don't think it as a blocker for the Linux kernel to merge as many hardwares' support as possible.</pre> </blockquote> We seem to have a misunderstanding here, this is not a software issue. The hardware platform is considered broken by the hardware vendor! In other words people have stitched together hardware in a way which is not supported by the creator of that hardware. So as long as you can't convince anybody from ARM or the RISC-V team or whoever created that hardware to confirm that the hardware actually works you won't get any support for that. Regards, Christian. </body> </html>