Message-ID: <5100C2A5.7040702@ti.com>
Date:	Thu, 24 Jan 2013 10:42:05 +0530
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Matt Porter <mporter@...com>
CC:	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Benoit Cousson <b-cousson@...com>,
	Arnd Bergmann <arnd@...db.de>,
	Linux Documentation List <linux-doc@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Linux MMC List <linux-mmc@...r.kernel.org>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Vinod Koul <vinod.koul@...el.com>,
	Rob Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
	Linux SPI Devel List 
	<spi-devel-general@...ts.sourceforge.net>,
	Chris Ball <cjb@...top.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 00/14] DMA Engine support for AM33XX

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 :-)

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

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists