On Fri, May 18, 2018 at 12:03 AM, Vinod <vkoul@xxxxxxxxxx> wrote: > > You are simply mixing things up! It certainly feels like I'm mixed up. If I have to resolve this, I'd like to be a little less mixed up before I submit more patches which are going to inevitably result in subtly broken code suddenly becoming prominently and unignorably broken code. Unfortunately I get the impression I'm exhausting your patience to answer my questions, and I've failed to fully communicate what the question is. > On Pause we don't expect data loss, as user can > resume the transfer. This means as you rightly guessed, the DMA HW should not drop > any data, nor should SW. > > Now if you want to read residue at this point it is perfectly valid. But if you > decide to terminate the channel (yes it is terminate_all API), we abort and don't > have context to report back! I understand the residue can't be read after terminate, that's why reading the residue is step 2 in pause/residue/terminate. My question was whether the entire sequence pause/residue/terminate taken as a whole can or cannot lose data. Saying that individual steps can or can't lose data is not enough, context is required. The key point is whether pause flushes in-flight data to its destination or not. If it does, and our residue is accurate, the terminate cannot cause data loss. If pause doesn't flush, an additional step of flush_sync as Lars suggested is required. So pause/flush_sync/residue/terminate would be the safe sequence that cannot lose data. > As Lars rightly pointed out, residue calculation are very tricky, DMA fifo may > have data, some data may be in device FIFO, so residue is always from DMA point > of view and may differ from device view (more or less depending upon direction) > > Now if you require to add more features for your usecase, please do feel free to > send a patch. The framework can always be improved, we haven't solved world > hunger yet! World hunger? I don't see how asking questions about a dma engine's data integrity guarantees is either unreasonable or out of scope. -- Frank -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |