linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Mori Hess <fmh6jj@gmail.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Vinod Koul <vkoul@kernel.org>,
	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>
Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Date: Tue, 8 May 2018 10:36:18 -0400	[thread overview]
Message-ID: <CAJz5OpcGX_3u5POExdhnBbRu-T-m7KodGAvk50BOfZWKeH--kg@mail.gmail.com> (raw)
In-Reply-To: <53b13d76-16a1-0e0a-09e1-c917e5d49326@samsung.com>

On Tue, May 8, 2018 at 5:04 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi Frank and Vinod,
>
> On 2018-04-28 23:50, Frank Mori Hess wrote:
>> This reverts commit 88987d2c7534a0269f567fb101e6d71a08f0f01d.
>>
>> The pl330.c pause implementation violates the dmaengine requirement
>> for no data loss, since it relies on the DMAKILL
>> instruction.  However, DMAKILL discards in-flight data from the
>> dma controller's fifo.  This is documented in the dma-330 manual
>> and I have observed it with hardware doing device-to-memory burst
>> transfers.  The discarded data may or may not show up in the
>> residue count, depending on timing (resulting in data corruption
>> effectively).
>>
>> Signed-off-by: Frank Mori Hess <fmh6jj@gmail.com>
>
> This revert completely breaks serial driver operation on almost all Exynos
> SoCs, because serial driver relies on having PAUSE feature and proper
> residue reporting from dma engine. Please drop it if possible.
>

It will cause the serial driver to not use the pl330.c driver for dma,
the serial driver will fall back on using the cpu.  This is
unfortunate, but the dma hardware simply does not support pause.  The
"nice" stop instruction DMAEND is not allowed to be inserted using the
debug instruction register.  The only possibility for implementing
pause would be to make the dma transfer do a DMAWFE (wait for event)
before every transfer.  Then you would need to devote another dma
thread to doing nothing but DMASEV (send event) to keep the transfer
going.  The pause could then DMAKILL the event-generating thread
rather than the transfer thread.  I don't know exactly what the
performance impact would be, but it couldn't be good.

The serial driver could be modified to still use dma for TX, since it
only needs pause for RX.  Also, if your serial hardware can report
exactly how many bytes it has sitting in its rx fifo, the serial
driver could be modified to use pause-less dma for RX.  This is
actually what I did for the custom serial hardware I'm using with a
dma-330, although our serial hardware has a very large rx fifo which
makes this scheme worthwhile.

  reply	other threads:[~2018-05-08 14:36 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 [this message]
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
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=CAJz5OpcGX_3u5POExdhnBbRu-T-m7KodGAvk50BOfZWKeH--kg@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=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).