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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
