DMA Engine development
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Frank Mori Hess <fmh6jj@gmail.com>
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: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Date: Fri, 18 May 2018 09:33:49 +0530	[thread overview]
Message-ID: <20180518040349.GB2932@vkoul-mobl> (raw)

On 17-05-18, 12:20, 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.
> 
> On Thu, May 17, 2018 at 12:19 AM, Vinod Koul <vinod.koul@linaro.org> wrote:
> >> > Terminate is abort, data loss may happen here.
> >>
> >> Wait, are you saying if you do
> >>
> >> dma pause
> >
> > no data loss
> >> read residue
> >
> > here as well
> >> dma terminate
> >
> > Oh yes, we aborted...
> >>
> 
> I see two ways of interpreting what you are saying. First, from the
> point of view of the user of the dmaengine api.  From this point of
> view it is impossible for data loss to occur during pause or reading
> the residue, so saying they cause no data loss during
> pause/residue/terminate is meaningless.  This is because the user
> can't confirm any data loss until after they have read the residue and
> the transfer is terminated, since optimistically the data may still be
> available if only the user would resume and allow the transfer to
> continue.
> 
> Second there is the interpretation I want to believe.  This is "no
> data loss on pause" means that after the pause, no data has been
> discarded by the dma controller hardware, in fact all the data it has
> read before being paused has been fully transferred to its
> destination.  Reading the residue while paused gives you an accurate,
> up-to-date state of the paused transfer.  Then finally, although in
> general dma terminate causes data loss, it does not in this case since
> we terminated while we were paused and read the up-to-date residue.
> This is the interpretation implicit in the 8250 serial driver.

You are simply mixing things up! 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!

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!

             reply	other threads:[~2018-05-18  4:03 UTC|newest]

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

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=20180518040349.GB2932@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=fmh6jj@gmail.com \
    --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 \
    /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