From: mporter@ti.com (Matt Porter)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common
Date: Fri, 21 Sep 2012 14:34:46 -0400 [thread overview]
Message-ID: <20120921183446.GH16522@beef> (raw)
In-Reply-To: <20120921094205.GC31374@n2100.arm.linux.org.uk>
On Fri, Sep 21, 2012 at 10:42:05AM +0100, Russell King wrote:
> On Fri, Sep 21, 2012 at 09:33:42AM +0000, Hebbar, Gururaja wrote:
> > On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote:
> > > On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> > > > Move mach-davinci/dma.c to common/edma.c so it can be used
> > > > by OMAP (specifically AM33xx atm) as well. This just moves
> > > > the private EDMA API but does not support OMAP.
> > > >
> > > > Signed-off-by: Matt Porter <mporter@ti.com>
> > > > ---
> > > > arch/arm/Kconfig | 1 +
> > > > arch/arm/common/Kconfig | 3 +
> > > > arch/arm/common/Makefile | 1 +
> > > > arch/arm/common/edma.c | 1588 ++++++++++++++++++++++++++++
> > > > arch/arm/include/asm/mach/edma.h | 267 +++++
> > >
> > > asm/mach should not be used as a dumping ground for platform header files.
> > > It is there to provide the interfaces between generic ARM architecture
> > > code and platform code. (At least four files that are there at the
> > > moment need to be moved out of there - patch series to follow...)
> >
> > Can this be moved to include/linux/platform_data/ ?
>
> Here's the pertinant question: "is it platform data?" Looking at the
> file, it appears to be internal data structures and register definitions
> for the driver itself. Therefore, it isn't platform data, and it
> shouldn't be living separately from the driver.
>
> If the driver itself only makes use of the data structures, the data
> structures should be defined either within the driver, or a header file
> co-located next to the driver itself. The same goes for register
> definitions too.
>
> The only structure that I can find which isn't internal to the driver
> is struct edma_soc_info, struct edma_rsv_info, and the enum dma_event_q.
> Those can go to include/linux/platform_data, but the rest should not.
Ok, but is it ok to keep the actual private EDMA API portion in
arch/arm/include/asm/mach/? It's not a problem to move the internal
portions to a local include and that pdata to the appropriate place.
We still need a place independent of mach-davinci and mach-omap2 to
keep that portion of the include. I suppose it could be put in with
the dmaengine wrapper's include/linux/edma.h but I hate to clutter
that up when the private API will go away later.
-Matt
next prev parent reply other threads:[~2012-09-21 18:34 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-20 14:43 [RFC PATCH 00/13] DMA Engine support for AM33xx Matt Porter
2012-09-20 14:43 ` [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common Matt Porter
2012-09-21 7:10 ` Hebbar, Gururaja
2012-09-21 18:24 ` Matt Porter
2012-09-21 9:29 ` Russell King - ARM Linux
2012-09-21 9:33 ` Hebbar, Gururaja
2012-09-21 9:42 ` Russell King - ARM Linux
2012-09-21 18:34 ` Matt Porter [this message]
2012-09-21 18:50 ` Russell King - ARM Linux
2012-09-24 2:44 ` Hebbar, Gururaja
2012-09-20 14:43 ` [RFC PATCH 02/13] ARM: edma: remove unused transfer controller handlers Matt Porter
2012-09-20 14:43 ` [RFC PATCH 03/13] ARM: edma: add DT and runtime PM support for AM335x Matt Porter
2012-09-21 8:53 ` Hebbar, Gururaja
2012-10-09 18:58 ` Matt Porter
2012-09-20 14:43 ` [RFC PATCH 04/13] dmaengine: edma: enable build " Matt Porter
2012-09-20 14:43 ` [RFC PATCH 05/13] dma: Add TI EDMA device tree binding Matt Porter
2012-09-21 8:45 ` Hebbar, Gururaja
2012-09-21 18:23 ` Matt Porter
2012-09-20 14:43 ` [RFC PATCH 06/13] ARM: omap: add hsmmc am33xx specific init Matt Porter
2012-09-20 14:43 ` [RFC PATCH 07/13] mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms Matt Porter
2012-09-20 22:16 ` Tony Lindgren
2012-09-20 14:43 ` [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC Matt Porter
2012-09-21 17:15 ` S, Venkatraman
2012-09-21 17:17 ` S, Venkatraman
2012-09-21 17:18 ` Felipe Balbi
2012-09-21 17:33 ` S, Venkatraman
2012-09-21 18:54 ` Matt Porter
2012-09-21 18:42 ` Matt Porter
2012-09-21 18:47 ` Russell King - ARM Linux
2012-09-21 19:03 ` Matt Porter
2012-09-27 9:41 ` Vinod Koul
2012-10-01 16:39 ` Matt Porter
2012-10-02 12:03 ` Vinod Koul
2012-09-20 14:43 ` [RFC PATCH 09/13] mmc: omap_hsmmc: add generic DMA request support to the DT binding Matt Porter
2012-09-20 14:43 ` [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms Matt Porter
2012-09-20 22:09 ` Tony Lindgren
2012-09-21 8:16 ` Arnd Bergmann
2012-09-21 15:42 ` Tony Lindgren
2012-09-21 18:37 ` Matt Porter
2012-09-27 9:36 ` Vinod Koul
2012-10-01 16:37 ` Matt Porter
2012-09-20 14:43 ` [RFC PATCH 11/13] spi: omap2-mcspi: add generic DMA request support to the DT binding Matt Porter
2012-09-20 14:43 ` [RFC PATCH 12/13] ARM: dts: add am33xx EDMA support Matt Porter
2012-09-20 14:43 ` [RFC PATCH 13/13] Documentation: add schedule for removing private EDMA API Matt Porter
2012-09-20 15:58 ` Mark Brown
2012-09-20 16:05 ` Matt Porter
2012-09-21 8:27 ` [RFC PATCH 00/13] DMA Engine support for AM33xx Hebbar, Gururaja
2012-09-21 18:22 ` Matt Porter
2012-09-24 11:26 ` Hebbar, Gururaja
2012-09-24 12:05 ` Matt Porter
2012-09-26 8:26 ` Hebbar, Gururaja
2012-09-26 13:01 ` Matt Porter
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=20120921183446.GH16522@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).