[PATCH V2] spi: bcm2835: enabling polling mode for transfers shorter than 30us
broonie at kernel.org
Sat Apr 18 03:42:02 PDT 2015
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...
Size: 473 bytes
Desc: Digital signature
More information about the linux-rpi-kernel