> > > Hardware coherency for DMA is the exception for low-end embedded MIPS > > > systems andgiven the CPU address your's is no exception from that. > > > > > > If your system was supporting hardware coherency for DMA I/O you would > > > have obtained a cachable CPU address like: > > > > > > dma_handle=0x026f0000 size=0x00010000 cpu_addr=0x826f0000 > > > ^^^ > > > > > > A 0x8??????? would be in KSEG0 so cachable. > > > > I do have a an embedded system. Are you saying that, in all likelyhood, > > I do not have coherency? If I understand you correctly, this is a bad > > thing right? Will I need to take extra care to work around this issue. > > > > So are you saying I would prefer a cpu_addr in the 0x8******* range? > > No. because you don't seem to have hw coherency. So, the address I received is in uncachable memory, and therefore, should look the same to all devices on the bus without hw cache coherency? > > > If it is true that I don't have hardware coherency should I still be > > using the pci_*_consistent api? Or should I switch to the > > dma_*_noncoherent api? Also what extra steps do I need to take to get > > this to work with a non-coherent system? > > What you were doing seemed to be the right thing. The API is supposed > to do the necessary address conversion and cache flushes for the driver. > That is the unchanged driver should work on any architecture. Should I need to do any explicit cache flushes in my code for hardware without cache coherency? If I wanted to do this what function should I use? > According to the current kernel code the PNX8550 non-coheren (aka software > coherency). Will this be a problem for what I'm trying to accomplish? That is dma on a pci device. Thanks, Jon
