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

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

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