RE: [PATCH 1/2] spi: atmel: Do not cancel a transfer upon any signal

[David Laight <David.Laight@ACULAB.COM>]

...
> Anyway, the whole issue started with commit e0205d6203c2 "spi: atmel:
> Prevent
> false timeouts on long transfers". Citing the commit message here:
>      "spi: atmel: Prevent false timeouts on long transfers
> 
>      A slow SPI bus clocks at ~20MHz, which means it would transfer about
>      2500 bytes per second with a single data line. Big transfers, like when
>      dealing with flashes can easily reach a few MiB. The current DMA
> timeout
>      is set to 1 second, which means any working transfer of about 4MiB will
>      always be cancelled.
> 
>      With the above derivations, on a slow bus, we can assume every byte
> will
>      take at most 0.4ms. Said otherwise, we could add 4ms to the 1-second
>      timeout delay every 10kiB. On a 4MiB transfer, it would bring the
>      timeout delay up to 2.6s which still seems rather acceptable for a
>      timeout.
> 
>      The consequence of this is that long transfers might be allowed, which
>      hence requires the need to interrupt the transfer if wanted by the
>      user. We can hence switch to the _interruptible variant of
>      wait_for_completion. This leads to a little bit more handling to also
>      handle the interrupted case but looks really acceptable overall.
> 
>      While at it, we drop the useless, noisy and redundant WARN_ON() call."
> 
> This calculation is actually wrong by factor 1000. A 20MHz SPI bus is not
> really slow and it will transfer ~2.5MB/s over a single lane.
> The calculation would be right for 20kHz but I think this is a more
> esoteric case, isn't it?

Some of the sums are wrong, but the conclusion might be right.
A 4MB transfer at 20MHz only has 5 clocks/byte - seems low if it
is only using 1 data bit.
The spi devices usually support 'nibble mode' for read/write that
will speed things up - provided the data lines are connected.

OTOH a better fix is (probably) to do the transfer in sane sized chunks.
The extra interrupt and code won't make much difference to something
that takes that long.

As an aside, has anyone managed to get an spi memory device to calculate
a CRC? The ones we have claim to support the request but I've failed to
get it to work.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)