All of lore.kernel.org
 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>,
	Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>
Subject: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Date: Fri, 11 May 2018 11:57:11 -0400	[thread overview]
Message-ID: <CAJz5OpfqGW73=XpJww-qOTTV2H0G+sY8UHt7c6L6k8aiAyAu-g@mail.gmail.com> (raw)

On Fri, May 11, 2018 at 8:57 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> Okay, so you don't have any evidence that DMA transfers done in single
> reads/writes is broken with the current cmd_pause implementation.

I think the easiest way to test this empirically would be to just hack
dmatest to do a bunch of mem-to-mem transfers which it pauses and
checks the copied data is consistent with the reported residue.  Also,
it would need to check the source/destination address registers in the
pl330 for evidence of bytes read but not written.  And the pl330.c
driver would need to be fixed to not ignore the requested maxburst
when doing mem-to-mem transfers.
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
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>,
	Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>
Subject: Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Date: Fri, 11 May 2018 11:57:11 -0400	[thread overview]
Message-ID: <CAJz5OpfqGW73=XpJww-qOTTV2H0G+sY8UHt7c6L6k8aiAyAu-g@mail.gmail.com> (raw)
In-Reply-To: <06f54061-c537-b399-e493-ec2cdf4def5d@samsung.com>

On Fri, May 11, 2018 at 8:57 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> Okay, so you don't have any evidence that DMA transfers done in single
> reads/writes is broken with the current cmd_pause implementation.

I think the easiest way to test this empirically would be to just hack
dmatest to do a bunch of mem-to-mem transfers which it pauses and
checks the copied data is consistent with the reported residue.  Also,
it would need to check the source/destination address registers in the
pl330 for evidence of bytes read but not written.  And the pl330.c
driver would need to be fixed to not ignore the requested maxburst
when doing mem-to-mem transfers.

             reply	other threads:[~2018-05-11 15:57 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 15:57 Frank Mori Hess [this message]
2018-05-11 15:57 ` Revert "dmaengine: pl330: add DMA_PAUSE feature" Frank Mori Hess
  -- strict thread matches above, loose matches on Subject: below --
2018-05-29  7:09 Vinod Koul
2018-05-29  7:09 ` Vinod
2018-05-29  5:17 Marek Szyprowski
2018-05-29  5:17 ` Marek Szyprowski
2018-05-23  5:39 Vinod Koul
2018-05-23  5:39 ` Vinod
2018-05-22 14:27 Frank Mori Hess
2018-05-22 14:27 ` Frank Mori Hess
2018-05-22  3:37 Vinod Koul
2018-05-22  3:37 ` Vinod Koul
2018-05-22  0:56 Frank Mori Hess
2018-05-22  0:56 ` Frank Mori Hess
2018-05-21  9:16 Vinod Koul
2018-05-21  9:16 ` Vinod Koul
2018-05-18 19:01 Frank Mori Hess
2018-05-18 19:01 ` Frank Mori Hess
2018-05-18 18:56 Frank Mori Hess
2018-05-18 18:56 ` Frank Mori Hess
2018-05-18  7:21 Vinod Koul
2018-05-18  7:21 ` Vinod
2018-05-18  6:28 Marek Szyprowski
2018-05-18  6:28 ` Marek Szyprowski
2018-05-18  4:03 Vinod Koul
2018-05-18  4:03 ` Vinod
2018-05-17 17:22 Lars-Peter Clausen
2018-05-17 17:22 ` Lars-Peter Clausen
2018-05-17 16:20 Frank Mori Hess
2018-05-17 16:20 ` Frank Mori Hess
2018-05-17  4:19 Vinod Koul
2018-05-17  4:19 ` Vinod Koul
2018-05-15 15:50 Frank Mori Hess
2018-05-15 15:50 ` Frank Mori Hess
2018-05-15 13:45 Vinod Koul
2018-05-15 13:45 ` Vinod
2018-05-15 12:24 Marek Szyprowski
2018-05-15 12:24 ` Marek Szyprowski
2018-05-15  6:21 Vinod Koul
2018-05-15  6:21 ` Vinod
2018-05-11 12:57 Marek Szyprowski
2018-05-11 12:57 ` Marek Szyprowski
2018-05-10 16:04 Frank Mori Hess
2018-05-10 16:04 ` Frank Mori Hess
2018-05-10  8:31 Marek Szyprowski
2018-05-10  8:31 ` Marek Szyprowski
2018-05-09 17:48 Frank Mori Hess
2018-05-09 17:48 ` Frank Mori Hess
2018-05-09 13:19 Marek Szyprowski
2018-05-09 13:19 ` Marek Szyprowski
2018-05-09  6:59 Vinod Koul
2018-05-09  6:59 ` Vinod Koul
2018-05-08 14:36 Frank Mori Hess
2018-05-08 14:36 ` Frank Mori Hess
2018-05-08  9:04 Marek Szyprowski
2018-05-08  9:04 ` Marek Szyprowski
2018-05-03 16:35 Vinod Koul
2018-05-03 16:35 ` [PATCH] " Vinod Koul
2018-05-03  9:01 Vinod Koul
2018-05-03  9:01 ` [PATCH] " Vinod Koul
2018-05-02 14:37 Frank Mori Hess
2018-05-02 14:37 ` [PATCH] " Frank Mori Hess
2018-05-02  4:32 Vinod Koul
2018-05-02  4:32 ` [PATCH] " Vinod Koul
2018-04-28 21:50 Frank Mori Hess
2018-04-28 21:50 ` [PATCH] " 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='CAJz5OpfqGW73=XpJww-qOTTV2H0G+sY8UHt7c6L6k8aiAyAu-g@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.