linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Mori Hess <fmh6jj@gmail.com>
To: Vinod <vkoul@kernel.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	r.baldyga@hackerion.com, Krzysztof Kozlowski <krzk@kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>
Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Date: Fri, 18 May 2018 14:56:39 -0400	[thread overview]
Message-ID: <CAJz5OpfSanwNS7Z=3FapR97XZzjWF_J23HqVouxVnPn2HwkKLw@mail.gmail.com> (raw)
In-Reply-To: <20180518040349.GB2932@vkoul-mobl>

On Fri, May 18, 2018 at 12:03 AM, Vinod <vkoul@kernel.org> 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

  parent reply	other threads:[~2018-05-18 18:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-28 21:50 [PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature" Frank Mori Hess
2018-05-02  4:32 ` Vinod Koul
2018-05-02 14:37   ` Frank Mori Hess
2018-05-03  9:01     ` Vinod Koul
2018-05-03 16:35 ` Vinod Koul
     [not found] ` <CGME20180508090407eucas1p13713284c2d3f5aa5c66f8d136be683c1@eucas1p1.samsung.com>
2018-05-08  9:04   ` Marek Szyprowski
2018-05-08 14:36     ` Frank Mori Hess
2018-05-09  6:59       ` Vinod Koul
2018-05-09 13:19       ` Marek Szyprowski
2018-05-09 17:48         ` Frank Mori Hess
2018-05-10  8:31           ` Marek Szyprowski
2018-05-10 16:04             ` Frank Mori Hess
2018-05-11 12:57               ` Marek Szyprowski
2018-05-11 15:57                 ` Frank Mori Hess
2018-05-15  6:21                 ` Vinod
2018-05-15 12:24                   ` Marek Szyprowski
2018-05-15 13:45                     ` Vinod
2018-05-15 15:50                   ` Frank Mori Hess
2018-05-17  4:19                     ` Vinod Koul
2018-05-17 16:20                       ` Frank Mori Hess
2018-05-17 17:22                         ` Lars-Peter Clausen
2018-05-18 19:01                           ` Frank Mori Hess
2018-05-18  4:03                         ` Vinod
2018-05-18  6:28                           ` Marek Szyprowski
2018-05-18  7:21                             ` Vinod
2018-05-29  5:17                               ` Marek Szyprowski
2018-05-29  7:09                                 ` Vinod
2018-05-18 18:56                           ` Frank Mori Hess [this message]
2018-05-21  9:16                             ` Vinod Koul
2018-05-22  0:56                               ` Frank Mori Hess
2018-05-22  3:37                                 ` Vinod Koul
2018-05-22 14:27                                   ` Frank Mori Hess
2018-05-23  5:39                                     ` Vinod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJz5OpfSanwNS7Z=3FapR97XZzjWF_J23HqVouxVnPn2HwkKLw@mail.gmail.com' \
    --to=fmh6jj@gmail.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=r.baldyga@hackerion.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).