I have a problem getting DMA on MCBSP3 receive-side to operate correctly. The data is clocked in externally at 32 bits per FS, and the DMA is set to receive one 32-bit word per frame, 16384 frames per block.


I get callbacks at the appropriate points (the correct number of words have been received at each callback, and the correct number of words seem to have been written to the buffer – also the ‘end of block’ status is being flagged and there are no error conditions).  But what is written to the buffer has no relationship to what is being received. I have good visibility on the latter, because the input is an incrementing 32-bit number from a test signal generator and is a known quantity, verified ‘in-flight’ by explicit reads of MCBSP3 DRR at the DMA callback.


The problem occurs identically on different DMA channel numbers.  I am using the MCBSP3 receive DMA request number (17, which is incremented to 18 before use).


Experimentation has shown that, for any given value of buffer address, a different set of word values (but constant per buffer address value!) is being written.


I assume this is some sort of memory mapping issue, but what?  The addressing would seem to be straightforward – the DMA engine requires the physical address of MCBSP3 DRR (it has it) and the physical address of the buffer (it has it).  The buffer is allocated through kmalloc(GFP_KERNEL | GFP_DMA). I note that the virt_to_bus() macro maps to virt_to_phys() in this architecture.


The problem occurs whether or not I implement an mmap of the buffer in my driver.


Have I missed something silly?  Is there a known problem here? 


Any help much appreciated!


Mike Turner