在 2024-07-02星期二的 11:27 +0200，Christian König写道： > Am 02.07.24 um 11:06 schrieb Icenowy Zheng: > > [SNIP] > > 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. > > 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] I don't think AGP spec is part of the PCIe spec, at least not part of the PCIe spec I was reading. It does not contain the word "AGP" at all, and despite it has a "Reference Documents" chapter, this chapter didn't include the AGP spec, unlike PCI spec / PCI-X addendum which are listed there. In addition, your logic that No-Snoop is related to AGP only apply when discussing about the history of PCIe, not when inspecting it from a synchronic view, which is what new implementers of a spec should do. > > > We have quite a bunch of V4L, sound and I also think network > > > devices > > > which work like that. But those are non-PCI devices. > > 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. > > Yes and that is absolutely intentional. > > See we don't want to support any non-coherent PCIe implementation. > However, considering users exist for this setup, I here seriously hope the support to be gained since today. > [SNIP] > > > 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. > > > > > 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. > > We seem to have a misunderstanding here, this is not a software > issue. > The hardware platform is considered broken by the hardware vendor! I don't think in this case Arm Ltd / RISC-V International is considered the vendor -- the SoC vendor is. You can rarely get support directly from the CPU ISA vendor (or CPU IP vendor, which differs mostly in the RISC-V situation) in the case a SoC or a final product with some SoC is purchased, and the SoC/product's vendor would rarely declare their hardware platform as broken. > > 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. The world isn't black-or-white, and the thing contradictory to "confirmed working" is "not confirmed working" instead of "confirmed not working". To get the thing really working (or prove it doesn't work at all by practice) is part of the traditional fun of a hacker. > > Regards, > Christian.
