[U-Boot] [PATCH v2] common/xyzModem.c: Fix delay timeout calculation

When waiting for input in CYGACC_COMM_IF_GETC_TIMEOUT we delay 2 seconds by incrementing and checking a counter variable every 20 uSeconds. The overhead in the loop calling tstc() thousands of times causes the timeout to be closer to 20 seconds. Delay longer per iteration to reduce overhead and bring the timeout back closer to the correct time.
Signed-off-by: Andrew F. Davis afd@ti.com --- common/xyzModem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/xyzModem.c b/common/xyzModem.c index 5656aac..390abdc 100644 --- a/common/xyzModem.c +++ b/common/xyzModem.c @@ -73,9 +73,9 @@ CYGACC_COMM_IF_GETC_TIMEOUT (char chan, char *c) { #define DELAY 20 unsigned long counter = 0; - while (!tstc () && (counter < xyzModem_CHAR_TIMEOUT * 1000 / DELAY)) + while (!tstc () && (counter < xyzModem_CHAR_TIMEOUT / DELAY)) { - udelay (DELAY); + mdelay (DELAY); counter++; } if (tstc ())

On Tue, Sep 20, 2016 at 10:39:49AM -0500, Andrew F. Davis wrote:
When waiting for input in CYGACC_COMM_IF_GETC_TIMEOUT we delay 2 seconds by incrementing and checking a counter variable every 20 uSeconds. The overhead in the loop calling tstc() thousands of times causes the timeout to be closer to 20 seconds. Delay longer per iteration to reduce overhead and bring the timeout back closer to the correct time.
Signed-off-by: Andrew F. Davis afd@ti.com
Reviewed-by: Tom Rini trini@konsulko.com

On 09/23/2016 02:57 PM, Tom Rini wrote:
On Tue, Sep 20, 2016 at 10:39:49AM -0500, Andrew F. Davis wrote:
When waiting for input in CYGACC_COMM_IF_GETC_TIMEOUT we delay 2 seconds by incrementing and checking a counter variable every 20 uSeconds. The overhead in the loop calling tstc() thousands of times causes the timeout to be closer to 20 seconds. Delay longer per iteration to reduce overhead and bring the timeout back closer to the correct time.
Signed-off-by: Andrew F. Davis afd@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
I was just informed that this may be breaking UART boot on a couple of our platforms, so this shouldn't be taken until I can get this figured out.
Thanks, Andrew
participants (2)
-
Andrew F. Davis
-
Tom Rini