* Russell King - ARM Linux | 2015-08-07 17:26:48 [+0100]: >On Fri, Aug 07, 2015 at 05:36:05PM +0200, Sebastian Andrzej Siewior wrote: >> + /* >> + * We do not allow DMA_MEM_TO_DEV transfers to be paused. >> + * According to RMK the OMAP hardware might prefetch bytes from >> + * memory into its FIFO and not send it to the device due to the >> + * pause. The bytes in the FIFO are cleared on pause. It is >> + * unspecified by how many bytes the source address is updated >> + * if at all. > >Would you mind rewording the above. > >Please take the time to read the manuals for the device you are playing >with. It's mostly documented in there. See the OMAP4430 ES2.x TRM, >16.4.18 and 16.4.19. I didn't connect the dots that well. Thank you. … I updated the comment to: /* * We do not allow DMA_MEM_TO_DEV transfers to be paused. * From the AM572x TRM, 16.1.4.18 Disabling a Channel During Transfer: * "When a channel is disabled during a transfer, the channel undergoes * an abort, unless it is hardware-source-synchronized …". * A source-synchronised channel is one where the fetching of data is * under control of the device. In other words, a device-to-memory * transfer. So, a destination-synchronised channel (which would be a * memory-to-device transfer) undergoes an abort if the the CCR_ENABLE * bit is cleared. * From 16.1.4.20.4.6.2 Abort: "If an abort trigger occurs, the channel * aborts immediately after completion of current read/write * transactions and then the FIFO is cleaned up." The term "cleaned up" * is not defined. TI recommends to check that RD_ACTIVE and WR_ACTIVE * are both clear _before_ disabling the channel, otherwise data loss * will occur. * The problem is that if the channel is active, then device activity * can result in DMA activity starting between reading those as both * clear and the write to DMA_CCR to clear the enable bit hitting the * hardware. If the DMA hardware can't drain the data in its FIFO to the * destination, then data loss "might" occur (say if we write to an UART * and the UART is not accepting any further data). */ would that be okay? >Due to this, the OMAP DMA engine driver was submitted with this in the >cover note: > >"For the OMAP DMAengine driver, there's a few short-comings: > >1. pause/resume support is not implemented; it's not clear whether the > OMAP hardware is capable of supporting this sanely." If I google for it, I find it. pause/resume support for cyclic was added later without a note why it is only supported for cyclic. Sebastian -- 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
