On Wed, Sep 26, 2012 at 08:26:19AM +0000, Hebbar, Gururaja wrote:

On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:

quoted

On Fri, Sep 21, 2012 at 08:27:07AM +0000, Hebbar, Gururaja wrote:

quoted

On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt 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.

There are a mind-boggling number of dependencies for this series:

	- Jon Hunter's OF DMA helpers series
	  https://patchwork.kernel.org/patch/1461061/
	  https://patchwork.kernel.org/patch/1461051/
	- Patch to address OF DMA helpers naming issues:
	  https://patchwork.kernel.org/patch/1477921/
	- EDMA DMA Engine wrapper driver in linux-next
	  c2dde5f8f2095d7c623ff3565c1462e190272273
	- EDMA DMA Engine wrapper driver bug fix:
	  https://patchwork.kernel.org/patch/1474411/  
	- A huge number of patches in linux-next for AM33xx boot
	  (too numerous to list)

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.

What works? Well, with this series we now have MMC and SPI support
on AM33xx. The only caveat for MMC is that the mmc3 controller has
its events on the crossbar and is not usable right now.

This is tested on BeagleBone with a SPI framebuffer driver and SD
card.

After this series, the plan is to convert the last in-tree user
of the private EDMA API (davinci-pcm/mcasp) and then eliminate
the private EDMA API by folding its functionality into
drivers/dma/edma.c.

TODO:
	add AM33xx crossbar support to the private EDMA API
	(any EDMA events on the crossbar are not supported)

Can you please mention the base repo you have taken as starting point.
(repo + extra patches ...).

It's mainline 3.6-rc6 and you can see the complete set of patches
at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2

quoted

This will help us to test the code.

This is because I looked at the patch 12/13 and I see that mmc
device-node is modified. But in mainline I don’t see device 
node for mmc (yet).

Oops. You'll need e62a3333ae450bcdefbe22229d7bc277ae0ef645 and
fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include
in this series. I'll have them in for v2.

Yesterday I tested edma patches on latest linux-next/master + merge of 
linux-omap/for_3.7/dts_part2. Below are my observations

1. baseline = linux-next/master + merge of linux-omap/for_3.7/dts_part2
2. on top of above branch, I applied patches [1-9]/13 of your edma 
   patches
3. few patches required trivial changes before applying
4. Applied dma of patches as you mentioned
5. add custom patch (ARM: CUSTOM: Build a uImage with dtb already 
   appended)
   From https://github.com/hvaibhav/am335x-linux/commit/
        7e72f5ed4b702c9373d19f7626f07ae31a381d53#arch/arm/Makefile

Alternatively you can run a current u-boot master build for am335x and
the appended dtb is no longer required.

Hrm, looks like a dts issue if it can't find the reg resource on your
integration of this. In any case, I'll look at it in v2.

With this I was able to boot on am335x-evm and do a successful MMC 
copy-md5sum-compare test.

Great! Thanks for testing this.

I believe you are looking into above issue in your v2 version.

Yes.

-Matt

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html