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

[Martin Sperl <kernel@xxxxxxxxxxxxxxxx>]

> On 15.04.2015, at 20:58, Mark Brown <broonie@xxxxxxxxxx> 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.

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?

Alternatively we would need some way to measure the time in uSeconds
quite accurately and then code some "rescheduling" detection into the
polling loop to modify the end-time if the thread got rescheduled or
otherwise interrupted for longer periods. Things would get complicated
here...

What kind of interface could we use for this timeout behavior?

The question here is - is the "simple" 1 second timeout approach
sufficient or would we need something more complex?

The patch removing the timeout worked for about 1.47B SPI messages
using the polling code-path now without issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html