> > > 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
|