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

[Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx>]

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.

The timeout itself is here to catch HW failures or erratas, I suppose it can
tolerate some minutes as well...

-- 
Best regards,
Alexander Sverdlin.
--
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