Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Mon, May 21, 2018 at 11:37 PM, Vinod Koul wrote: > > Well looks like even adding support for sync_pause doesn't solve your issue on > pl330. Do you want to move this to PIO mode then..? > I'm not sure what you think my issue is with the pl330, are you confusing me with

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Mon, May 21, 2018 at 11:37 PM, Vinod Koul wrote: > > Well looks like even adding support for sync_pause doesn't solve your issue on > pl330. Do you want to move this to PIO mode then..? > I'm not sure what you think my issue is with the pl330, are you confusing me with Marek? My position is

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Mon, May 21, 2018 at 5:16 AM, Vinod Koul wrote: >> >> 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 >>

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Mon, May 21, 2018 at 5:16 AM, Vinod Koul wrote: >> >> 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

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Thu, May 17, 2018 at 1:22 PM, Lars-Peter Clausen <l...@metafoo.de> wrote: > On 05/17/2018 06:20 PM, Frank Mori Hess wrote: > The problem is not so much on the software side but even more so on the > hardware side. Not all hardware even supports aborting a transfer with no >

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Thu, May 17, 2018 at 1:22 PM, Lars-Peter Clausen wrote: > On 05/17/2018 06:20 PM, Frank Mori Hess wrote: > The problem is not so much on the software side but even more so on the > hardware side. Not all hardware even supports aborting a transfer with no > data loss because there i

Re: 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

Re: 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

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

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

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

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

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Tue, May 15, 2018 at 2:21 AM, Vinod wrote: > > For Pause/resume data loss is _not_ expected. > >> > and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it >> > can't count on the pause/residue/terminate working without data loss >> > then it is just broken.

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Tue, May 15, 2018 at 2:21 AM, Vinod wrote: > > For Pause/resume data loss is _not_ expected. > >> > and some of the 8250 drivers like 8250_dw.c set a maxburst > 1. If it >> > can't count on the pause/residue/terminate working without data loss >> > then it is just broken. As is the

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Fri, May 11, 2018 at 8:57 AM, Marek Szyprowski 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

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Fri, May 11, 2018 at 8:57 AM, Marek Szyprowski 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

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Thu, May 10, 2018 at 4:31 AM, Marek Szyprowski <m.szyprow...@samsung.com> wrote: > Hi Frank, > > On 2018-05-09 19:48, Frank Mori Hess wrote: >> On Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski >> <m.szyprow...@samsung.com> wrote: >>> I unders

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Thu, May 10, 2018 at 4:31 AM, Marek Szyprowski wrote: > Hi Frank, > > On 2018-05-09 19:48, Frank Mori Hess wrote: >> On Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski >> wrote: >>> I understand that pl330 doesn't support real PAUSE, but as it has been >>

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski wrote: > > I understand that pl330 doesn't support real PAUSE, but as it has been > implemented since 2015 the limited support is perfectly possible - just > to let serial driver to read the amount of data transferred. > >

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Wed, May 9, 2018 at 9:19 AM, Marek Szyprowski wrote: > > I understand that pl330 doesn't support real PAUSE, but as it has been > implemented since 2015 the limited support is perfectly possible - just > to let serial driver to read the amount of data transferred. > > Please note that DMA

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Tue, May 8, 2018 at 5:04 AM, Marek Szyprowski <m.szyprow...@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 v

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Tue, May 8, 2018 at 5:04 AM, Marek Szyprowski 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

Re: [PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Wed, May 2, 2018 at 12:32 AM, Vinod Koul <vinod.k...@intel.com> wrote: > On Sat, Apr 28, 2018 at 05:50:58PM -0400, Frank Mori Hess wrote: >> This reverts commit 88987d2c7534a0269f567fb101e6d71a08f0f01d. >> > > I am dropping the orignal patch for queue, so no need f

Re: [PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Wed, May 2, 2018 at 12:32 AM, Vinod Koul wrote: > On Sat, Apr 28, 2018 at 05:50:58PM -0400, Frank Mori Hess wrote: >> This reverts commit 88987d2c7534a0269f567fb101e6d71a08f0f01d. >> > > I am dropping the orignal patch for queue, so no need for revert patch.

[PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

-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 <fmh...@gmail.com> --- drivers/dma/pl330.

[PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

-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 --- drivers/dma/pl330.c | 28

[PATCH v5] dmaengine: pl330: flush before wait, and add dev burst support.

dregs with either single transfers for peripherals, or with a reduced size burst for memory-to-memory transfers. Signed-off-by: Frank Mori Hess <fmh...@gmail.com> Tested-by: Frank Mori Hess <fmh...@gmail.com> --- I tested dma transfers to peripherals with v3 patch and designware serial p

[PATCH v5] dmaengine: pl330: flush before wait, and add dev burst support.

dregs with either single transfers for peripherals, or with a reduced size burst for memory-to-memory transfers. Signed-off-by: Frank Mori Hess Tested-by: Frank Mori Hess --- I tested dma transfers to peripherals with v3 patch and designware serial port (drivers/tty/serial/8250/8250_dw.c

Re: [PATCH v4] dmaengine: pl330: flush before wait, and add dev burst support.

On Tue, Apr 10, 2018 at 11:37 AM, Vinod Koul wrote: >> >> Hi, what is the state of this patch? I just noticed in patchwork it >> is now listed as "Not applicable"? The original broken-by-wordwrap >> patch is listed as "Accepted"? >> >>

Re: [PATCH v4] dmaengine: pl330: flush before wait, and add dev burst support.

On Tue, Apr 10, 2018 at 11:37 AM, Vinod Koul wrote: >> >> Hi, what is the state of this patch? I just noticed in patchwork it >> is now listed as "Not applicable"? The original broken-by-wordwrap >> patch is listed as "Accepted"? >> >>

Re: [PATCH v4] dmaengine: pl330: flush before wait, and add dev burst support.

On Tue, Mar 13, 2018 at 2:34 PM, Frank Mori Hess <fmh...@gmail.com> wrote: > Do DMAFLUSHP _before_ the first DMAWFP to ensure controller > and peripheral are in agreement about dma request state before first > transfer. Add support for burst transfers to/from peripherals. In t

Re: [PATCH v4] dmaengine: pl330: flush before wait, and add dev burst support.

On Tue, Mar 13, 2018 at 2:34 PM, Frank Mori Hess wrote: > Do DMAFLUSHP _before_ the first DMAWFP to ensure controller > and peripheral are in agreement about dma request state before first > transfer. Add support for burst transfers to/from peripherals. In the new > scheme, the con

[PATCH v4] dmaengine: pl330: flush before wait, and add dev burst support.

dregs with either single transfers for peripherals, or with a reduced size burst for memory-to-memory transfers. Signed-off-by: Frank Mori Hess <fmh...@gmail.com> Tested-by: Frank Mori Hess <fmh...@gmail.com> --- I tested dma transfers to peripherals with v3 patch and designware serial p

[PATCH v4] dmaengine: pl330: flush before wait, and add dev burst support.

dregs with either single transfers for peripherals, or with a reduced size burst for memory-to-memory transfers. Signed-off-by: Frank Mori Hess Tested-by: Frank Mori Hess --- I tested dma transfers to peripherals with v3 patch and designware serial port (drivers/tty/serial/8250/8250_dw.c

Re: [PATCH v3] dmaengine: pl330: flush before wait, and add dev burst support.

On Sun, Mar 11, 2018 at 11:01 AM, Vinod Koul wrote: > > sorry if it wasnt clear earlier, the lines below should come after the --- > line. git-am skips that part while applying.. ok >> >> + /* do FLUSHP at beginning to clear any stale dma requests before the >> +

Re: [PATCH v3] dmaengine: pl330: flush before wait, and add dev burst support.

On Sun, Mar 11, 2018 at 11:01 AM, Vinod Koul wrote: > > sorry if it wasnt clear earlier, the lines below should come after the --- > line. git-am skips that part while applying.. ok >> >> + /* do FLUSHP at beginning to clear any stale dma requests before the >> + * first WFP. >> +

[PATCH v3] dmaengine: pl330: flush before wait, and add dev burst support.

dregs with either single transfers for peripherals, or with a reduced size burst for memory-to-memory transfers. Signed-off-by: Frank Mori Hess <fmh...@gmail.com> Tested-by: Frank Mori Hess <fmh...@gmail.com> I tested dma transfers to peripherals with designware serial port (drivers/tty

[PATCH v3] dmaengine: pl330: flush before wait, and add dev burst support.

dregs with either single transfers for peripherals, or with a reduced size burst for memory-to-memory transfers. Signed-off-by: Frank Mori Hess Tested-by: Frank Mori Hess I tested dma transfers to peripherals with designware serial port (drivers/tty/serial/8250/8250_dw.c) and a GPIB interface