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

[Mark Brown]

On Sat, Apr 18, 2015 at 03:31:13PM +0200, Martin Sperl wrote:

> > On 18.04.2015, at 14:27, Mark Brown <broonie at kernel.org> wrote:
> > That's probably fine, though the 40ms is a bit on the long side.  The
> > 30s timeout could use pulling in too, that's going to fail very badly if
> > anything does go wronng.

> Anything below 2 jiffies will give enough false positives during a kernel
> recompile - the original code has had 2 jiffies as the effective minimum,
> because the calculated delivery-time of max 30us is still orders of magnitudes
> smaller than a single jiffy, but a reschedule can happen, which would be the
> main reason why we have had triggered timeouts before.

Sure, but with the fallback to a much longer sleeping delay that'd be
covered transparently anyway - it doesn't matter if we don't always
manage to busy wait under load, what's more important is that we don't
fail the operation as a whole.

Actually if it's just scheduling that's a concern then one final check
after the time expires should do the trick shouldn't it?

> SO IMO anything shorter than 2-3 jifies would need to use a new framework to
> get access to high-resolution timers - and I do not know how to do that.

hrtimer_ is the high resolution timer stuff, though I don't think it's
really what you're looking for, it's more about async callbacks IIRC.
-------------- 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/c209fa77/attachment.sig>