| Message ID | 1397134229-2380-1-git-send-email-harinik@xilinx.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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).
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));
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(-)