On 05/17/2018 06:20 PM, Frank Mori Hess wrote: > Sorry to keep coming back to this, but I'm experiencing a bit of > incredulity that you are saying what you seem to be saying. You seem > to be saying dmaengine provides no way to permanently stop a transfer > safely other than transferring the full number of bytes initially > requested. So the proper resolution is the 8250 serial driver needs > to remove rx dma support, because they are just trying to do something > that is not supported. The problem is not so much on the software side but even more so on the hardware side. Not all hardware even supports aborting a transfer with no data loss because there is no precise measurement of how much data has been transferred. The residue that is reported is always the lower bound, this much has been transferred but it might actually have been more. And even if hardware supports precise residue reporting there often is no synchronization mechanism to ensure that there is no pending data anywhere in the pipeline. This doesn't even have to be inside the DMA's buffers, the DMA might have send the data to the peripheral but it has not arrived at the peripheral side. If the peripheral has a memory mapped FIFO there will typically be some confirmation that the data was received, but with a dedicated DMA bus between the DMA controller and the peripheral that is often not the case. And for the first case the DMA controller also needs to actually expose the information how many acknowledgements it has received. Because there are basically two different resides, residue one is how much data has been read from/written to memory and the other is how much data has been read from/written to the peripheral. Any differences between the two will account for in flight data. What I'd recommend is to add a flush_sync() operation to the DMA interface. This function would wait until all in flight data transfers have been completed. That makes it safe to call terminate() without the risk of loosing data and also allow accurate residue reporting. Although I'd expect that there is fair risk that implementations will not get flush_sync() 100% correct because it requires in-depth knowledge about the internal behavior of the DMA which is often not documented. -- 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
