[PATCH] spi: core: Increase timeout value

[PATCH] spi: core: Increase timeout value

[Harini Katakam]

The existing timeout value in wait_for_completion_timeout is
calculated from the transfer length and speed with tolerance of 10msec.
This is too low because this is used for error conditions such as
hardware hang etc.
The xfer->speed_hz considered may not be the actual speed set
because the best clock divisor is chosen from a limited set such that
the actual speed <= requested speed. This will lead to timeout being
less than actual transfer time.
Considering acceptable latencies, this timeout can be set to a large
value >= 1*HZ typically.
This patch adds a tolerance of 2000 msec in the core accordingly.

Signed-off-by: Harini Katakam <harinik@xilinx.com>
---
 drivers/spi/spi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 4eb9bf0..3fdecfa 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -775,7 +775,7 @@ static int spi_transfer_one_message(struct spi_master *master,
 		if (ret > 0) {
 			ret = 0;
 			ms = xfer->len * 8 * 1000 / xfer->speed_hz;
-			ms += 10; /* some tolerance */
+			ms += 2000; /* some tolerance */
 
 			ms = wait_for_completion_timeout(&master->xfer_completion,
 							 msecs_to_jiffies(ms));
-- 
1.7.9.5

Re: [PATCH] spi: core: Increase timeout value

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Thu, Apr 10, 2014 at 06:20:29PM +0530, Harini Katakam wrote:

> Considering acceptable latencies, this timeout can be set to a large
> value >= 1*HZ typically.

> This patch adds a tolerance of 2000 msec in the core accordingly.

That's too much, it's 2 seconds which gets to be incredibly painful when
trying to debug problems - if you're sitting there waiting for a driver
to time out some operations (and it may be more than one of them) so you
can look at the diagnostics it can be quite aggrivating.  That's why the
delays are related to the expected runtime for the operation.  Something
like double the expected runtime plus something in the 100ms or so range
perhaps?

Ideally we'd use the actual speed the device set rather than the
requested one too, that'd help.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: core: Increase timeout value

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Thu, Apr 10, 2014 at 06:20:29PM +0530, Harini Katakam wrote:

> Considering acceptable latencies, this timeout can be set to a large
> value >= 1*HZ typically.

> This patch adds a tolerance of 2000 msec in the core accordingly.

That's too much, it's 2 seconds which gets to be incredibly painful when
trying to debug problems - if you're sitting there waiting for a driver
to time out some operations (and it may be more than one of them) so you
can look at the diagnostics it can be quite aggrivating.  That's why the
delays are related to the expected runtime for the operation.  Something
like double the expected runtime plus something in the 100ms or so range
perhaps?

Ideally we'd use the actual speed the device set rather than the
requested one too, that'd help.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] spi: core: Increase timeout value

[Harini Katakam]

Hi Mark,

On Thu, Apr 10, 2014 at 11:06 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Apr 10, 2014 at 06:20:29PM +0530, Harini Katakam wrote:
>
>> Considering acceptable latencies, this timeout can be set to a large
>> value >= 1*HZ typically.
>
>> This patch adds a tolerance of 2000 msec in the core accordingly.
>
> That's too much, it's 2 seconds which gets to be incredibly painful when
> trying to debug problems - if you're sitting there waiting for a driver
> to time out some operations (and it may be more than one of them) so you
> can look at the diagnostics it can be quite aggrivating.  That's why the
> delays are related to the expected runtime for the operation.  Something
> like double the expected runtime plus something in the 100ms or so range
> perhaps?
>

OK.

> Ideally we'd use the actual speed the device set rather than the
> requested one too, that'd help.

How would you propose to do that - driver should write back actual speed set
to xfer->speed_hz?

Regards,
Harini

Re: [PATCH] spi: core: Increase timeout value

[Harini Katakam]

Hi Mark,

On Thu, Apr 10, 2014 at 11:06 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Apr 10, 2014 at 06:20:29PM +0530, Harini Katakam wrote:
>
>> Considering acceptable latencies, this timeout can be set to a large
>> value >= 1*HZ typically.
>
>> This patch adds a tolerance of 2000 msec in the core accordingly.
>
> That's too much, it's 2 seconds which gets to be incredibly painful when
> trying to debug problems - if you're sitting there waiting for a driver
> to time out some operations (and it may be more than one of them) so you
> can look at the diagnostics it can be quite aggrivating.  That's why the
> delays are related to the expected runtime for the operation.  Something
> like double the expected runtime plus something in the 100ms or so range
> perhaps?
>

OK.

> Ideally we'd use the actual speed the device set rather than the
> requested one too, that'd help.

How would you propose to do that - driver should write back actual speed set
to xfer->speed_hz?

Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: core: Increase timeout value

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Fri, Apr 11, 2014 at 08:39:54AM +0530, Harini Katakam wrote:
> On Thu, Apr 10, 2014 at 11:06 PM, Mark Brown <broonie@kernel.org> wrote:

> > Ideally we'd use the actual speed the device set rather than the
> > requested one too, that'd help.

> How would you propose to do that - driver should write back actual speed set
> to xfer->speed_hz?

I'm thinking something more like having a variable in the driver struct
for the current speed (like you do in your own and some others do).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]