Re: [PATCH v5 00/14] DMA Engine support for AM33XX

[Matt Porter <mporter@ti.com>]

On Thu, Jan 24, 2013 at 05:12:05AM +0000, Shilimkar, Santosh wrote:
> On Thursday 24 January 2013 02:19 AM, Matt Porter wrote:
> > On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote:
> >> Matt,
> >>
> >> On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote:
> >>
> >> [..]
> >>
> >>> 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 :-)

Great!

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

BTW, since I'm dropping mmc support from this series, I'll move your
patch into a separate series with only the mmc pieces.

-Matt