spi: bcm2835aux: fixed bad data on longer transfers

There are strange issues with the auxiliary spi device that result
in "lost" data in the RX path if the fifo is filled by too much
(even though the status register is checked if new data can get filled
in).

This has been observed primarily for the interrupt case.
Polling works fine, probably because the RX fifo is pulled immediately
when in the tight polling loop.

For that reason we have to limit the pending bytes to less than 15
when filling the fifo in interrupt mode.

There also was an issue returning the "wrong" last 1/2 bytes
of a transfer when the transfer is not a multiple of 3 bytes.
(this impacted polling and interrupt modes)

Also fixed an overflow in the estimation of the transfer time used
to decide if we run in interrupt or polling mode (found with the
spi-bcm2835.c driver originally).

Reported-by: Georgii Staroselskii <georgii.staroselskii@emlid.com>
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>