>> thread). On some PPC's like PReP, the mapping between bus addresses >> and CPU physical addresses on PCI isn't 1:1 and the system RAM is >> not mapped at 0 for bus mastering PCI devices. If you use the PCI >> DMA API, things are ok. If you aren't, then some tweaks may be needed. >> (See the definition of deprecated virt_to_bus in asm-ppc/io.h) > >The DRM doesn't use the PCI DMA API. Instead does everything manually. > >Why do you say virt_to_bus is deprecated? Where can I find more >information about these APIs?
Kernel's Documentation/DMA-mapping.txt is your friend ;) Though virt_to_bus should still work, at least on PReP. Beware of 2 things that can happen on non-x86 archs: - The PCI BAR values can't be used directly for ioremap, use the pci resources provided by the kernel PCI layer, those may have been "fixed up" in cases where the CPU->PCI space isn't 1:1 physically. But I don't think this is your problem. - The RAM may not be at 0 from PCI view, but in those cases, either the PCI DMA APIs or virt_to_bus should do the right thing. Though, as Leif pointed out, it's a Mac, so none of the above issues should matter, except if you are trying to tap the card's VGA IOs, but that's a different story. As far as UniNorth (yet, all AGP macs have the uninorth chipset) is concerned, the only working version so far is the one in my rsync kernel tree, I never merged it upstream as it requires a few hacks to the DRM and I never manage to have it stable (not the uninorth code itself, which is pretty trivial, but for some reasons, both r128's and Radeon's exhibit occasionnal lockups when used with AGP on Mac with UniNorth chipset. I've tried all sort of things, like reading the chip's ring write ptr instead of relying on the one written to memory, adding delay's, etc... but so far had no success). Ben. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
