All STM32 host drivers. In IN endpoint retry, delay for a clock tick to give some breathing space for the CPU. EXPERIMENTAL change.

This commit is contained in:
Gregory Nutt 2017-03-10 10:25:11 -06:00
parent 5ec25a87c9
commit 24816cb08b
4 changed files with 32 additions and 0 deletions

View File

@ -1906,6 +1906,14 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx,
return (ssize_t)ret;
}
/* Wait a bit before retrying after a NAK.
*
* REVISIT: This is intended to give the CPU a break from
* the tight polling loop. But are there performance issues?
*/
usleep(1000);
}
}
else

View File

@ -1911,6 +1911,14 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx,
return (ssize_t)ret;
}
/* Wait a bit before retrying after a NAK.
*
* REVISIT: This is intended to give the CPU a break from
* the tight polling loop. But are there performance issues?
*/
usleep(1000);
}
}
else

View File

@ -1905,6 +1905,14 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx,
return (ssize_t)ret;
}
/* Wait a bit before retrying after a NAK.
*
* REVISIT: This is intended to give the CPU a break from
* the tight polling loop. But are there performance issues?
*/
usleep(1000);
}
}
else

View File

@ -1910,6 +1910,14 @@ static ssize_t stm32l4_in_transfer(FAR struct stm32l4_usbhost_s *priv,
return (ssize_t)ret;
}
/* Wait a bit before retrying after a NAK.
*
* REVISIT: This is intended to give the CPU a break from
* the tight polling loop. But are there performance issues?
*/
usleep(1000);
}
}
else