Re: u64 fun and PCI DMA not working for things behind bridges?

Benjamin Herrenschmidt [off-list ref] writes:

quoted

The firewire device is behind the same bridge the GMAC is behind. Is
there something special I need to do to make physical dma work all the
time when the device you are dma'ing to/from is behind a bridge?

It could be a hardware implementation problem in the uni-north FW, of
course. I'm just trying to see if anyone has ever noticed anything.


Right now i have to resort to having the SBP-2 driver emulate physical
dma reads/writes by telling the firewire subsystem driver to redirect
all reads/writes into host memory through a routine that simply does
memcpys.
I also tell the controller it's not allowed to allow physical dma
accesses to be performed (there are filter registers that let you
specify what addresses you'll allow physical dma access to, and what
you want to go through the normal block read/write/quadlet read/write
process) , and that the other side must do it through normal block
reads/write packets.

This works, but it's a little slow, of course.

It might be possible that we have an apple bug here... Could you try
doing as if the device was not cache coherent ?

I'm on it.

Basically, invalidate the cache for a data block that will be filled by
the device, and flush the cache for a data block that will be read by the
device. You can do the first one with dcbi, the second with dcbf, both
loops followed by a "sync" instruction to make sure the ache operations
are completed.

This would, of course, be much easier if i had something snooping the
1394 bus, so i could see if it's even really *trying* to do the DMA.

The thing that makes me think it is is the fact that i get random
kernel crashes right after it should be doing the DMA (IE it's
writing the wrong memory).

Let me give your idea a try.

Ben

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/