[PATCH V2] spi: bcm2835: enabling polling mode for transfers shorter than 30us

[Mark Brown]

On Wed, Apr 15, 2015 at 09:33:48PM +0200, Martin Sperl wrote:
> > On 15.04.2015, at 20:58, Mark Brown <broonie at kernel.org> wrote:

> > Running without a timeout doesn't feel safe - the standard thing here is
> > to busy wait for a short period then fall back to something that sleeps
> > if that times out.

> That is what is implemented now, but unfortunately the issue is that the 
> implementation as of now is depending on jiffies, which I found out to be
> in the order of 10ms and on top requires a timer interrupt which would
> interrupt polling in the first place. But it is still sensitive enough
> to trigger on some rescheduling of the polling thread.

Then that's not what is implemented...  I'd expect something like a busy
wait loop done by something like dead reckoning the number of iterations
followed by msleep() if we go beyond the busy loop period.

> One possibility could be increasing the timeout to something longer like
> one second or a fraction of one second.

> Something along those lines:
> -	unsigned long timeout = jiffies +
> -		max(4 * xfer_time_us * HZ / 1000000, 2uL);
> +	/* one second timeout - this should also allow for graceful
> +	 * timeouts even when experiencing rescheduling of the thread
> +	 */
> +	unsigned long timeout = jiffies + HZ;

> Would this be sufficient and acceptable?

No, we need to not busy wait for that long.

> The patch removing the timeout worked for about 1.47B SPI messages
> using the polling code-path now without issues.

Sure, if everythinng is working fine then there's never any need to time
out - the question is what happens when things go wrong.  A hard lockup
probably isn't the answer people were looking for there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20150418/8718b6eb/attachment.sig>