Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 2017-11-10 17:24, Tony Lindgren wrote:
>> I run out of time few days ago already, but this looks so good that it is
>> worth to delay other work. I'll include it in next version of patch serie.
>>
>> Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
>> is configured which was intended logic of original driver. 'dma-channel'
>> was introduced during mechanical conversion to DT and fortunately it is
>> not used yet, so we can safely remove it again.
> 
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

My conversion to DMAengine is drop in replacement of the existing
implementation: memcpy w/o hardware synchronization event.

But I think it should be possible to use HW sync (slave DMA) with the
src/dst_port_window in a similar way we do with the tusb6010.

But that can be done in a followup series, but what to do in case of old
DT where the dmas/dma-names properties are no there?

Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.

Having said that, there might have been a reason why the original
implementation was not using DMA request to trigger the memcpy... The
legacy omap-dma API would have allowed that as you kind of open code
things with much flexibility.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki