From: mporter@ti.com (Matt Porter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
Date: Tue, 18 Sep 2012 09:21:13 -0400 [thread overview]
Message-ID: <20120918132113.GT27758@beef> (raw)
In-Reply-To: <1347938035.1943.162.camel@vkoul-udesk3>
On Tue, Sep 18, 2012 at 08:43:55AM +0530, Vinod Koul wrote:
> On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote:
> > >
> > > I believe that Jon is on vacation this week, so if this is the only issue
> > > holding up the merge, maybe you can change this in his patch directly, or
> > > I can send an updated version if you prefer.
> >
> > I worry that too much is going on here too quickly. We have some people
> > working on changing the way DMA engine selects channels. Meanwhile we
> > have other people trying to create an OF DMA engine API.
> >
> > It seems that Vinod's working on a way for platforms to specify bindings
> > to the DMA engine code, and the DMA engine code itself selects the
> > appropriate channel. This patch, on the other hand, introduces a set of
> > translation functions which need to be provided by platform code,
> > which returns the dma_chan pointer.
> >
> > This sounds like a recipe for a total abortion of interfaces. Only one
> > of those two activities should be going on at any one time, or if they
> > have to occur, they need coordination so that the we don't end up with
> > two totally different schemes.
> >
> > In the mad rush to DTify everything, don't make hasty decisions, because
> > it is very difficult to change it later - especially something like this
> > which defines how DT encodes this information.
> We discussed this in KS and IMHO we need to merge these two approaches.
>
> For DT bindings, I think the binding itself shouldn't change based on my
> work but I would like these same bindings to help build the DMA engine
> code mappings.
>
> Now would it make sense to NOT merge these changes for 3.7 and postpone
> to 3.8. I can host these patches on a topic branch and merge them when
> we are ready. I plan to spend some good amount of time on my work this
> week so we should be ready pretty soon.
> One these changes are merged, users can start moving to this scheme.
FWIW, I'm already basing the EDMA dmaengine support for OMAP (specifically
for AM335x) on using these helpers since AM335x *only* boots from DT.
-Matt
next prev parent reply other threads:[~2012-09-18 13:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 22:41 [PATCH V6 0/2] of: Add generic device tree DMA helpers Jon Hunter
2012-09-14 22:41 ` [PATCH V6 1/2] " Jon Hunter
2012-09-14 22:46 ` Stephen Warren
2012-09-15 0:14 ` Russell King - ARM Linux
2012-09-17 20:42 ` Arnd Bergmann
2012-09-17 23:06 ` David Brown
2012-09-18 12:50 ` Arnd Bergmann
2012-09-18 22:19 ` Mitch Bradley
2012-09-18 22:32 ` Russell King - ARM Linux
2012-09-19 11:09 ` Arnd Bergmann
2012-09-19 14:40 ` Mitch Bradley
2012-09-19 13:52 ` Matt Porter
2012-09-19 14:07 ` Matt Porter
2012-09-19 14:24 ` Arnd Bergmann
2012-09-19 14:36 ` Rob Herring
2012-09-19 14:40 ` Matt Porter
2012-09-19 14:50 ` Arnd Bergmann
2012-09-19 21:25 ` Mitch Bradley
2012-09-19 14:10 ` Rob Herring
2012-09-14 22:41 ` [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel Jon Hunter
2012-09-17 3:33 ` Vinod Koul
2012-09-17 11:59 ` Arnd Bergmann
2012-09-17 22:36 ` Russell King - ARM Linux
2012-09-18 3:13 ` Vinod Koul
2012-09-18 13:21 ` Matt Porter [this message]
2012-09-18 15:20 ` Arnd Bergmann
2012-09-18 18:10 ` Russell King - ARM Linux
2012-09-24 22:25 ` Jon Hunter
2012-09-25 4:35 ` Vinod Koul
2012-10-16 2:43 ` Shawn Guo
2012-10-16 2:39 ` Vinod Koul
2012-11-09 20:01 ` Jon Hunter
2012-11-16 1:37 ` Vinod Koul
2012-11-16 8:39 ` Nicolas Ferre
2012-11-16 15:45 ` Jon Hunter
2012-11-28 17:06 ` Vinod Koul
2012-12-19 17:12 ` Jon Hunter
2012-12-20 14:57 ` Vinod Koul
2012-09-18 3:00 ` Vinod Koul
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=20120918132113.GT27758@beef \
--to=mporter@ti.com \
--cc=linux-arm-kernel@lists.infradead.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).