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

[Martin Sperl <kernel@xxxxxxxxxxxxxxxx>]

> On 18.04.2015, at 12:42, Mark Brown <broonie@xxxxxxxxxx> wrote:
> 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.

Well that is why I have implemented the 1s timeout patch,
which you have already merged (145367baa492246). 

Such a timeout would typically also trigger a messages to
dmesg, so it becomes apparent that such a situation happened.

The only issues that could really trigger a timeout would be:
* heavy load on the system, where it takes >1s to reschedule
  the polling thread - but if you get to such a situation then
  all bets are off anyway.
* a hick-up in hardware 

As said: I have tried one type of load where I had something like
3000M SPI messages all running with polling  (about 18000 per second)
without any issues or timeouts while compiling the linux kernel.
And except for rescheduling the polling thread and the corresponding
delays there were no issues with the 1s timeout - it never triggered!

If you think that timeout of 1 second is too long, then we can change
it to something more acceptable, but it should be in the order of
100ms or more to avoid those “false” positives due to high cpu load
that the original code showed.

--
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