[PATCH] Device Tree binding for the 'mv_xor' XOR engine DMA driver

[Andrew Lunn]

> > The dmatest shows up a second issue:
> > 
> > root at qnap:~# insmod ./dmatest.ko iterations=100
> > dmatest: Started 2 threads using dma0chan0
> > dmatest: Started 2 threads using dma1chan0
> > dmatest: Started 2 threads using dma2chan0
> > dmatest: Started 2 threads using dma3chan0
> > dma3chan0-xor0: #3: prep error with src_off=0x13c2 dst_off=0x2c7c
> > len=0x5d
> > dma1chan0-copy0: #16: prep error with src_off=0x1f50 dst_off=0x904
> > len=0x33
> > dma3chan0-copy0: #22: prep error with src_off=0x14c2 dst_off=0x389b
> > len=0x6f
> > dma0chan0-copy0: #31: prep error with src_off=0x10b6 dst_off=0x323c
> > len=0x2f
> > dma3chan0-copy0: #49: prep error with src_off=0x17b5 dst_off=0x3eca
> > len=0x29
> > 
> > The driver refuses any operation where the buffer is less than 128 bytes. The
> > datasheet for Kirkwood says the buffer length must be 8 bytes or more. So
> > maybe we should reduce this 128 limit down to 8?
> 
> This limitation (128B) is only in memset operations (set in registers and not descriptors).
> If I recall correctly the limit is 16B and not 8B.
> 
> In any way, this 128 bytes seems like a good logical boundary for XOR HW enabling. (performance wise)

Hi Lior

Agreed. Anything smaller than that, and you spend more time setting up
the hardware and dealing with interrupts when its finished than doing
it in software.

I had quick look at some of the call sites. Users of the DMA API under
the crypto directory all fall back to software operations when the DMA
API returns an error. Also, raid uses the crypto API for memcpy and
XOR. So raid seems O.K. I could not find any other users of the DMA
API for _xor, _copy, or _memset. So it seems safe to return an error
for inefficient usage.

      Andrew