On Tue, 2018-01-02 at 11:22 +0100, Ludovic Desroches wrote:
> On Wed, Dec 27, 2017 at 10:40:00PM +0100, Cyrille Pitchen wrote:
>
> > Or maybe no change at all is required at the at_xdmac.c driver side: we
> > just don't care about the provided flags in the "dmas" property, especially
> > the "peripheral id". They would be ignored anyway when the atmel-quadspi.c
> > driver later calls dmaengine_prep_dma_memcpy(). So I could simply set the
> > dma cells to 0 in the device-tree?
> >
> > Ludovic, what do you think about that ?
>
> It may work but I won't do this. Usually, channels requested through the xlate
> function have usually their capaiblities set to DMA_SLAVE and not DMA_MEMCPY.
> In the at_xdmac case, it won't be an issue but if you have a controller
> which has channels which can support only mem-to-mem or peripheral, it
> won't work.
Maybe one could create an "AT91_XDMAC_DT_" macro to indicate a memcpy
channel. There are still unused bits for another flag. It also looks
like at_xdma uses peripheral id 0x3f for memcpy transfers (will that
work with memcpy DMA on multiple channels at the same time?). So
perhaps perid 0x3f could be the indication of wanting a memcpy channel,
rather than another flag bit. But however it's done, one writes:
dmas = <&dma0 AT91_XDMAC_DT_MEMCPY>; dma-names = "rx-tx";
I think one could have the quadspi driver automatically fill in the dma
cell in the dma specifier if it is not present in the device tree. So
one could write "dmas = <&dma0>" and the driver adds the
AT91_XDMAC_DT_MEMCPY cell before xlating. I'm not sure if that's a
good idea or not.��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
