On Thursday 24 January 2013 02:19 AM, Matt Porter wrote:

On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote:

quoted

Matt,

On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote:

[..]

quoted

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.8-rc3 and the following patches:

	- TPS65910 REGMAP_IRQ build fix:
	  https://patchwork.kernel.org/patch/1857701/
	- dmaengine DT support from Vinod's dmaengine_dt branch in
	  git://git.infradead.org/users/vkoul/slave-dma.git since
	  027478851791df751176398be02a3b1c5f6aa824
	- edma dmaengine driver fix:
	  https://patchwork.kernel.org/patch/1961521/
	- dmaengine dma_get_channel_caps v2:
	  https://patchwork.kernel.org/patch/1961601/
	- dmaengine edma driver channel caps support v2:
	  https://patchwork.kernel.org/patch/1961591/

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 we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.

With this series both BeagleBone and the AM335x EVM have working
MMC and SPI support.

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. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4
has the complete series, dependencies, and some test
drivers/defconfigs.

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 (14):
   ARM: davinci: move private EDMA API to arm/common
   ARM: edma: remove unused transfer controller handlers
   ARM: edma: add AM33XX support to the private EDMA API
   dmaengine: edma: enable build for AM33XX
   dmaengine: edma: Add TI EDMA device tree binding
   ARM: dts: add AM33XX EDMA support
   dmaengine: add dma_request_slave_channel_compat()
   mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
   mmc: omap_hsmmc: set max_segs based on dma engine limitations
   mmc: omap_hsmmc: add generic DMA request support to the DT binding
   ARM: dts: add AM33XX MMC support
   spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
   spi: omap2-mcspi: add generic DMA request support to the DT binding
   ARM: dts: add AM33XX SPI DMA support

While going through the series and testing it out, I observed an issue
with MMC driver. You need patch in the end of the email to avoid the
issue. Same is attached in case mailer damages it. Can you please
add it with your series if you agree ?

Yes, by inspection this makes sense. As you noticed, we've been relying
on the fact that DMA resources still don't come from DT, we only use our
DT data in conjunction with the DMA OF helpers to do channel filtering.
I was figuring we would address that separately later, but I see how
even omap4 has this issue with DMA resources named with "tx1", for
example. A good followup once this series is taken will be to only
use hwmod resources on a !populated-dt platform like we do for other
resources now. Baby steps. :)

We are already on it :-)

Thanks for the catch, I'll add this in with your tested line as well for
the series.

Thanks.

Regards,
Santosh