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. It supports aligned power-of-two transfers up to its bus width (typ 16 bytes), and aligned bursts of its bus width up to the configured max burst length (typ 4 or 8 beats) but never crossing a (4 KB) page boundary. If you ask it for anything else it will simply use the smallest supported transfer that covers the requested range, and uses byte-masking for writes. Beware that this means that e.g. a transfer with (len == 8 && addr % 8 == 4) is not considered properly aligned even if the target's actual bus width is 32-bit! The important property of the target therefore is: does it support masked writes? I did a few tests of interesting peripherals on the DM814x, and it turns out the results are quite diverse (and utterly undocumented). control module: despite all the magic there it seems to correctly support reads and writes of any size, including masked writes. hwspinlock module, lock registers: surprisingly these properly support aligned 1- and 2-byte accesses, with the lock residing in byte 0 of each word and bytes 1-3 being RAZ/WI. Masked writes however are only supported if all or no bytes of each word are masked. If some but not all bytes of a word are masked a bus error is generated. ethernet dma descriptor ram: ignores byte-masking hence masked writes cause silent corruption!! Aligned 1- and 2-byte accesses get the same treatment. Note in particular that using edma to write words 1 and 2 of an ethernet dma descriptor would corrupt words 0 and 3 of that descriptor. This is not something I would have expected even though I already knew the descriptor memory only supported word-writes. Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
