Re: [PATCH] spi: pl022: Remove timeout in polling mode operation

[Lars-Peter Clausen <lars@xxxxxxxxxx>]

On 07/16/2018 10:05 AM, Alexander Sverdlin wrote:
> Hello!
> 
> On 15/07/18 20:03, Lars-Peter Clausen wrote:
>>>> Some tests show, that bulk SPI accesses (255 bytes, maximum PL022 can) may
>>>> take seconds, depending on CPU load. In this case vital SPI accesses can
>>>> fail because of user-space applications. Some other drivers already do not
>>>> have timeouts in polling mode.
>>>>
>>>> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx>
>>> Wow what system is this and how does that happen?
>>>
>>> I guess it is fine, but the timeout is there for a reason still. What about
>>> setting the timeout to a minute or something?
>> How about resetting the timeout if there is progress? E.g. have
>> readwriter() return whether it was able to read or write some data and
>> then reset the timeout. If the timeout is due to CPU contention
>> readwriter() should always be able to push/pull new data to/from the
>> hardware.
> 
> Well, if it's scheduled at all. In our case a poor task is not scheduled at all
> for 1-2 seconds (because of other high prio tasks which are here for a reason as
> well).
> So from the priority PoV we can allow a task reading from MTD to wait couple of
> seconds, but it's really strange for it to fail even though the MTD media itself
> is not corrupted.
> The risk increases with the number of tasks and hundreds of tasks in startup is
> not seldom and if one has HZ=100... This 1 second timeout is prone to fail
> in highly loaded system.

You'd run readwriter() before checking the timeout and reset the timeout if
it is able to make progress. Only if there was no progress you'd check the
timeout.
--
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