On 3 October 2016 at 10:00, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: > On 10/03/16 09:37, Matthijs van Duin wrote: >> I recently noticed the curious definition DMA_SLAVE_BUSWIDTH_3_BYTES >> and EDMA's supposed support thereof. While I appreciate it might just >> be a convenient hack to support dma for packed 24-bit audio, I feel it >> can use some clarification (and warning). >> >> EDMA does not really support 3-byte transfers. > > In A-Synchronized transfer the eDMA will transfer ACNT number of bytes in > response to a DMA request. ACNT valid values are 1 to 65535, including 3, 21, etc. > > Also there are not alignment restrictions from eDMA to SRC or DST address. The > only exception is SAM/DAM in constant addressing mode where the SRC/DST should > be 256bit aligned. None of this contradicts what I said. It isn't hard to verify that it implicitly performs larger aligned transfers, this shows up in various situations such as the examples I gave. It also shows up in the L3 interconnect error log when a read or write hits a disabled target or address hole. For another example, I created a 16-byte aligned buffer containing: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F I then did an edma transfer with ACNT=3 from this buffer to an FF-filled ethernet dma descriptor, then dumped the descriptor: 10 11 12 13 FF FF FF FF FF FF FF FF FF FF FF FF This shows unambiguously that edma transferred 4 bytes, even though it will have requested to mask byte 3 of the 4-byte write (a request ignored by the ethernet dma descriptor memory). > As far as I can see the eDMA itself does not have alignment restrictions, but > the peripheral might have. The peripheral is on a 32-bit bus and is not the source of alignment restrictions more stringent than 32-bit. The problem is that violating edma's alignment causes it to use masked writes, but this peripheral ignores the mask and exposes the aligned 16-byte write that edma actually performed. Matthijs -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
