[patch V2 0/6] dma: edma: Provide granular residue accounting

[patch V2 0/6] dma: edma: Provide granular residue accounting

[Thomas Gleixner]

A simpler version to provide granular residue accounting and readout
for EDMA.

Delta to V1:

      - Removed the double read of the address in PaRAM

      - Simplified the stats update in the interrupt callback for
        intermediate transfers

Thanks,

	tglx

[patch V2 2/6] dma: edma: Check the current decriptor first in tx_status()

[Thomas Gleixner]

An embedded and charset-unspecified text was scrubbed...
Name: dma-edma-tx-status-check-current-desc-first.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140428/4419ac4d/attachment.ksh>

[patch V2 1/6] dma: edma: Sanitize residue reporting

[Thomas Gleixner]

An embedded and charset-unspecified text was scrubbed...
Name: dma-edma-sanitize-residue-reporting.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140428/41e3656c/attachment.ksh>

[patch V2 3/6] dma: edma: Create private pset struct

[Thomas Gleixner]

An embedded and charset-unspecified text was scrubbed...
Name: dma-edma-create-private-pset-struct.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140428/05c1b24e/attachment.ksh>

[patch V2 5/6] edma: Make reading the position of active channels work

[Thomas Gleixner]

An embedded and charset-unspecified text was scrubbed...
Name: arm-edma-make-read-position-useful.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140428/ac025ce8/attachment.ksh>

[patch V2 5/6] edma: Make reading the position of active channels work

[Sekhar Nori]

On Monday 28 April 2014 04:19 PM, Thomas Gleixner wrote:

> As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
> the parameter ram. That's not synchronized with the internal update as
> it does a byte by byte copy. We need to do a 32bit read to get a
> consistent value.
> 
> Further reading destination and source is pointless. In DEV_TO_MEM
> transfers we are only interested in the destination, in MEM_TO_DEV we
> care about the source. In MEM_TO_MEM it really does not matter which
> one you read.
> 
> Simple solution: Remove the pointers, select dest/source via a bool
> and return the read value.

> Remove the export of this function while at it. The only potential
> user is the dmaengine and that's always builtin.

While this is true today, there are other DMA drivers which
are modules.

> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Irrespective of above,

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

[patch V2 5/6] edma: Make reading the position of active channels work

[Joel Fernandes]

On 04/28/2014 05:49 AM, Thomas Gleixner wrote:
> As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
> the parameter ram. That's not synchronized with the internal update as
> it does a byte by byte copy. We need to do a 32bit read to get a
> consistent value.
> 
> Further reading destination and source is pointless. In DEV_TO_MEM
> transfers we are only interested in the destination, in MEM_TO_DEV we
> care about the source. In MEM_TO_MEM it really does not matter which
> one you read.
> 
> Simple solution: Remove the pointers, select dest/source via a bool
> and return the read value.
> 
> Remove the export of this function while at it. The only potential
> user is the dmaengine and that's always builtin.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Thanks, this looks good.

Acked-by: Joel Fernandes <joelf@ti.com>


Regards,
-Joel

[patch V2 4/6] dma: edma: Store transfer data in edma_desc and edma_pset

[Thomas Gleixner]

An embedded and charset-unspecified text was scrubbed...
Name: dma-edma-store-per-pset-info.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140428/60959b39/attachment.ksh>

[patch V2 6/6] dma: edma: Provide granular accounting

[Thomas Gleixner]

An embedded and charset-unspecified text was scrubbed...
Name: dma-edma-provide-granular-accounting.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140428/91648c28/attachment.ksh>

[patch V2 0/6] dma: edma: Provide granular residue accounting

[Joel Fernandes]

On 04/28/2014 05:49 AM, Thomas Gleixner wrote:
> A simpler version to provide granular residue accounting and readout
> for EDMA.
> 
> Delta to V1:
> 
>       - Removed the double read of the address in PaRAM
> 
>       - Simplified the stats update in the interrupt callback for
>         intermediate transfers
> 
> Thanks,
> 
> 	tglx
> 

Thanks for the series. I went over all the patches and it looks great.
Acked-by: Joel Fernandes <joelf@ti.com>

The patches however didn't apply and had some conflicts with my dma
memcpy series and peter's cyclic series so I resolved conflicts and
created a single branch based on Vinod's slave-dma next branch (commit
406efb1a745c1dc512dc9c3c859e302e7b7f907e) that Vinod can pull.

I also renamed subject line of patches in Thomas's series to be
"dmaengine: edma" and documented some of the variables used.

https://github.com/joelagnel/linux-kernel.git (for-vinod branch)

Vinod, could you pull if it looks OK?

regards,
-Joel

[patch V2 0/6] dma: edma: Provide granular residue accounting

[Vinod Koul]

On Mon, Apr 28, 2014 at 03:47:37PM -0500, Joel Fernandes wrote:
> On 04/28/2014 05:49 AM, Thomas Gleixner wrote:
> > A simpler version to provide granular residue accounting and readout
> > for EDMA.
> > 
> > Delta to V1:
> > 
> >       - Removed the double read of the address in PaRAM
> > 
> >       - Simplified the stats update in the interrupt callback for
> >         intermediate transfers
> > 
> > Thanks,
> > 
> > 	tglx
> > 
> 
> Thanks for the series. I went over all the patches and it looks great.
> Acked-by: Joel Fernandes <joelf@ti.com>
> 
> The patches however didn't apply and had some conflicts with my dma
> memcpy series and peter's cyclic series so I resolved conflicts and
> created a single branch based on Vinod's slave-dma next branch (commit
> 406efb1a745c1dc512dc9c3c859e302e7b7f907e) that Vinod can pull.
> 
> I also renamed subject line of patches in Thomas's series to be
> "dmaengine: edma" and documented some of the variables used.
> 
> https://github.com/joelagnel/linux-kernel.git (for-vinod branch)
> 
> Vinod, could you pull if it looks OK?

The patches look good.

But,
commit 770f0f3a20188b7e17db2790803b9da925dc0b94
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Apr 28 10:49:43 2014 +0000

    dmaengine: edma: Make reading the position of active channels work

    As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
    the parameter ram. That's not synchronized with the internal update as
    it does a byte by byte copy. We need to do a 32bit read to get a
    consistent value.

    Further reading destination and source is pointless. In DEV_TO_MEM
    transfers we are only interested in the destination, in MEM_TO_DEV we
    care about the source. In MEM_TO_MEM it really does not matter which
    one you read.

    Simple solution: Remove the pointers, select dest/source via a bool
    and return the read value.

    Remove the export of this function while at it. The only potential
    user is the dmaengine and that's always builtin.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo
this or prefer me to cherry-pick patches adding acks and your s-o-b, since I
already fetched your branch

Either way is fine with me...

-- 
~Vinod

[patch V2 0/6] dma: edma: Provide granular residue accounting

[Joel Fernandes]

On 04/29/2014 03:46 AM, Vinod Koul wrote:
[..]
> commit 770f0f3a20188b7e17db2790803b9da925dc0b94
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Mon Apr 28 10:49:43 2014 +0000
> 
>     dmaengine: edma: Make reading the position of active channels work
> 
>     As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
>     the parameter ram. That's not synchronized with the internal update as
>     it does a byte by byte copy. We need to do a 32bit read to get a
>     consistent value.
> 
>     Further reading destination and source is pointless. In DEV_TO_MEM
>     transfers we are only interested in the destination, in MEM_TO_DEV we
>     care about the source. In MEM_TO_MEM it really does not matter which
>     one you read.
> 
>     Simple solution: Remove the pointers, select dest/source via a bool
>     and return the read value.
> 
>     Remove the export of this function while at it. The only potential
>     user is the dmaengine and that's always builtin.
> 
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo
> this or prefer me to cherry-pick patches adding acks and your s-o-b, since I
> already fetched your branch
> 
> Either way is fine with me...
> 

If its Ok with you, it would great if you could add my Ack and Sob.
Thanks a lot. Let me know if you'd want me to do anything else here.

Regards,
-Joel

[patch V2 0/6] dma: edma: Provide granular residue accounting

[Vinod Koul]

On Tue, Apr 29, 2014 at 11:25:02PM -0500, Joel Fernandes wrote:
> On 04/29/2014 03:46 AM, Vinod Koul wrote:
> [..]
> > commit 770f0f3a20188b7e17db2790803b9da925dc0b94
> > Author: Thomas Gleixner <tglx@linutronix.de>
> > Date:   Mon Apr 28 10:49:43 2014 +0000
> > 
> >     dmaengine: edma: Make reading the position of active channels work
> > 
> >     As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
> >     the parameter ram. That's not synchronized with the internal update as
> >     it does a byte by byte copy. We need to do a 32bit read to get a
> >     consistent value.
> > 
> >     Further reading destination and source is pointless. In DEV_TO_MEM
> >     transfers we are only interested in the destination, in MEM_TO_DEV we
> >     care about the source. In MEM_TO_MEM it really does not matter which
> >     one you read.
> > 
> >     Simple solution: Remove the pointers, select dest/source via a bool
> >     and return the read value.
> > 
> >     Remove the export of this function while at it. The only potential
> >     user is the dmaengine and that's always builtin.
> > 
> >     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > 
> > You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo
> > this or prefer me to cherry-pick patches adding acks and your s-o-b, since I
> > already fetched your branch
> > 
> > Either way is fine with me...
> > 
> 
> If its Ok with you, it would great if you could add my Ack and Sob.
> Thanks a lot. Let me know if you'd want me to do anything else here.
Done, The changes are getting pushed, pls do verify

-- 
~Vinod

[patch V2 0/6] dma: edma: Provide granular residue accounting

[Joel Fernandes]

On Wed, Apr 30, 2014 at 12:08 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Tue, Apr 29, 2014 at 11:25:02PM -0500, Joel Fernandes wrote:
>> On 04/29/2014 03:46 AM, Vinod Koul wrote:
>> [..]
>> > commit 770f0f3a20188b7e17db2790803b9da925dc0b94
>> > Author: Thomas Gleixner <tglx@linutronix.de>
>> > Date:   Mon Apr 28 10:49:43 2014 +0000
>> >
>> >     dmaengine: edma: Make reading the position of active channels work
>> >
>> >     As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
>> >     the parameter ram. That's not synchronized with the internal update as
>> >     it does a byte by byte copy. We need to do a 32bit read to get a
>> >     consistent value.
>> >
>> >     Further reading destination and source is pointless. In DEV_TO_MEM
>> >     transfers we are only interested in the destination, in MEM_TO_DEV we
>> >     care about the source. In MEM_TO_MEM it really does not matter which
>> >     one you read.
>> >
>> >     Simple solution: Remove the pointers, select dest/source via a bool
>> >     and return the read value.
>> >
>> >     Remove the export of this function while at it. The only potential
>> >     user is the dmaengine and that's always builtin.
>> >
>> >     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> >
>> > You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo
>> > this or prefer me to cherry-pick patches adding acks and your s-o-b, since I
>> > already fetched your branch
>> >
>> > Either way is fine with me...
>> >
>>
>> If its Ok with you, it would great if you could add my Ack and Sob.
>> Thanks a lot. Let me know if you'd want me to do anything else here.
> Done, The changes are getting pushed, pls do verify

Sorry for the late reply as I'm at a conference.

Thanks, I verified and it looks OK.

Regards,
-Joel