> Joakim Tjernlund writes:
>
> > m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
> > on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
> > hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI
> > driver
> > hung as soon you tried to read something.
>
> Then m8xx_cpm_hostalloc should be changed so it returns the DMA
> address along with the virtual address (of the uncached mapping).
>
> An alternative which will work, at least at present, is to use iopa()
> on the virtual address. However, that assumes that DMA bus addresses
> are identical to CPU physical addresses. That is true at the moment
> on all embedded PPC platforms that I know of currently, but there is
> no guarantee that it will always be true. That is why I think it is
> better to make a practice of saving the DMA address that you get back
> from consistent_alloc and using that.
Is consistent_alloc really needed? All uses I have seen in the kernel for the
8xx CPU can be solved with
a kmalloc(or a static char buffer) and a invalidate_dcache_range
call(flush_dcache_range if the buffer isn't cache line aligned).
This usally eliminates a memcpy() from uncached memory. See the 8xx_io/enet.c
patch I sent to
this list a few weeks ago. One guy converted that patch to the 8260 FEC and had
a 20% increase in performace
for big packets in his router.
Jocke
PS.
I still think the 'sync' instruction in invalidate_dcache_range is unneed.
I have been running my system
without it for a few weeks now and it still works as it should.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
