From: Vinod Koul <vinod.koul@intel.com>
To: Joel Fernandes <joelf@ti.com>
Cc: nsekhar@ti.com, Peter Ujfalusi <peter.ujfalusi@ti.com>,
dmaengine@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [patch V2 0/6] dma: edma: Provide granular residue accounting
Date: Tue, 29 Apr 2014 14:16:35 +0530 [thread overview]
Message-ID: <20140429084635.GN32284@intel.com> (raw)
In-Reply-To: <535EBE69.6060803@ti.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch V2 0/6] dma: edma: Provide granular residue accounting
Date: Tue, 29 Apr 2014 14:16:35 +0530 [thread overview]
Message-ID: <20140429084635.GN32284@intel.com> (raw)
In-Reply-To: <535EBE69.6060803@ti.com>
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
next prev parent reply other threads:[~2014-04-29 8:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 10:49 [patch V2 0/6] dma: edma: Provide granular residue accounting Thomas Gleixner
2014-04-28 10:49 ` [patch V2 2/6] dma: edma: Check the current decriptor first in tx_status() Thomas Gleixner
2014-04-28 10:49 ` [patch V2 1/6] dma: edma: Sanitize residue reporting Thomas Gleixner
2014-04-28 10:49 ` [patch V2 3/6] dma: edma: Create private pset struct Thomas Gleixner
2014-04-28 10:49 ` [patch V2 5/6] edma: Make reading the position of active channels work Thomas Gleixner
2014-04-28 14:44 ` Sekhar Nori
2014-04-28 16:11 ` Joel Fernandes
2014-04-28 10:49 ` [patch V2 4/6] dma: edma: Store transfer data in edma_desc and edma_pset Thomas Gleixner
2014-04-28 10:49 ` [patch V2 6/6] dma: edma: Provide granular accounting Thomas Gleixner
2014-04-28 20:47 ` [patch V2 0/6] dma: edma: Provide granular residue accounting Joel Fernandes
2014-04-28 20:47 ` Joel Fernandes
2014-04-29 8:46 ` Vinod Koul [this message]
2014-04-29 8:46 ` Vinod Koul
2014-04-30 4:25 ` Joel Fernandes
2014-04-30 4:25 ` Joel Fernandes
2014-04-30 5:08 ` Vinod Koul
2014-04-30 5:08 ` Vinod Koul
2014-05-01 1:57 ` Joel Fernandes
2014-05-01 1:57 ` Joel Fernandes
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=20140429084635.GN32284@intel.com \
--to=vinod.koul@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=joelf@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=tglx@linutronix.de \
/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.