[PATCH v11 0/8] ] DMA Engine support for AM33XX
From: Joel A Fernandes
Date: Tue Jun 18 2013 - 02:41:24 EST
This series is a repost of Matt Porter's EDMA patches for AM33XX EDMA support
with changes for few pending review comments on v9 series.
Currently this is required for AM33XX (Beaglebone or EVM) to access MMC
and be able mount to rootfs and boot till command prompt over MMC.
Unless there are other pending review comments, I hope this series can
make it into 3.11 merge window, the dependent series has been posted at 
and completed review.
Tested EDMA on AM1808 EVM and AM33XX Beaglebone with MMC.
Sekhar Nori has posted a GIT PULL  which has 2 patches this series depends on:
Changes since v10:
- Reworked documentation based on Arnd's feedback
- Moved EDMA bindings documentation earlier in series
- Dropped mention on am33xx on 2/8 and 3/8 in the series
Changes since v9:
- Droped reserved and queue DT entries from Documentation
for now from the original patch series.
- Drop DT entries that are non-hardware-description
- Split EDMA xbar support out of original EDMA DT parsing patch
to keep it easier for review.
- Rewrite shift and offset calculation xbar event mapping.
- Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in.
- Split out xbar stuff to separate patch.
Changes since v8:
- Removed edma node interrupt-parent property, it is inherited
Changes since v7:
- Dropped dmaengine compat() patch. It is upstream.
- Submitted edma_alloc_slot() error checking bug fix separately,
now a dependency
- Fixed bisect issues due to 3/10 hunks that went into 1/10
- Fixed incorrect IS_ERRVALUE() use in 3/10
Changes since v6:
- Converted edma_of_read_*() to wrappers around of_property_read_*()
- Fixed wording on the omap-spi generic DMA properties
- Added comment/check to clarify that the driver only supports
a single EDMA instance when booting from DT
Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support
Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
removed some unneeded definitions
- Fixed parsing of optional properties
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.10-rc4.
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so the upstream generic DT DMA helpers are
leveraged to register EDMA DMAC with the of_dma framework. SPI (and
MMC in a separate series) are supported using the upstream
dma_request_slave_channel_compat() dmaengine call that allows
compatibility with !DT platforms.
With this series both BeagleBone and the AM335x EVM have working
SPI DMA support (and MMC support with the separate MMC series).
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. Note that MMC can only
be tested with a separate MMC dmaengine/DT series applied.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (8):
dmaengine: edma: Add TI EDMA device tree binding
ARM: edma: Add DT and runtime PM support to the private EDMA API
ARM: edma: Add EDMA crossbar event mux support
ARM: dts: add AM33XX EDMA support
ARM: dts: add AM33XX SPI DMA support
dmaengine: edma: enable build for AM33XX
spi: omap2-mcspi: add generic DMA request support to the DT binding
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Documentation/devicetree/bindings/dma/ti-edma.txt | 34 +++
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 ++-
arch/arm/boot/dts/am33xx.dtsi | 22 ++
arch/arm/common/edma.c | 249 +++++++++++++++++++-
arch/arm/mach-omap2/Kconfig | 1 +
drivers/dma/Kconfig | 2 +-
drivers/spi/spi-omap2-mcspi.c | 64 +++--
include/linux/platform_data/edma.h | 5 +-
8 files changed, 368 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/