[lkml]   [2018]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Revert "dmaengine: pl330: add DMA_PAUSE feature"
On Fri, May 18, 2018 at 12:03 AM, Vinod <> 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.


 \ /
  Last update: 2018-05-18 20:57    [W:0.131 / U:1.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site