From 7ffbb704d66c75c84f9b4b346092b8e96ca3421f Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Sun, 21 May 2017 14:28:29 -0600 Subject: [PATCH] This is based on a patch by Taras Drozdovsky. Basically, the delay that was added during the integration of the CDC/ACM host driver was interfering with streaming audio. That delay was put there to prevent build endpoints from hogging the system bandwidth. So what do we do? Do we hog the bandwidth or do we insert arbitrarity delays. I think both ideas such. --- arch/arm/src/stm32/stm32_otgfshost.c | 21 ++++++++++++++++----- arch/arm/src/stm32/stm32_otghshost.c | 21 ++++++++++++++++----- arch/arm/src/stm32f7/stm32_otghost.c | 21 ++++++++++++++++----- 3 files changed, 48 insertions(+), 15 deletions(-) diff --git a/arch/arm/src/stm32/stm32_otgfshost.c b/arch/arm/src/stm32/stm32_otgfshost.c index b28226f5f2..bf3bbc8b91 100644 --- a/arch/arm/src/stm32/stm32_otgfshost.c +++ b/arch/arm/src/stm32/stm32_otgfshost.c @@ -1952,14 +1952,25 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx, delay = 1000; } - /* Wait for the next polling interval. + /* Wait for the next polling interval. For interrupt and + * isochronous endpoints, this is necessaryto assure the + * polling interval. It is used in other cases only to + * prevent the polling from consuming too much CPU bandwith. * - * REVISIT: This delay could require more resolution than - * is provided by the system timer. In that case, the - * delay could be significantly longer than required. + * Small delays could require more resolution than is provided + * by the system timer. For example, if the system timer + * resolution is 10MS, then usleep(1000) will actually request + * a delay 20MS (due to both quantization and rounding). + * + * REVISIT: So which is better? To ignore tiny delays and + * hog the system bandwidth? Or to wait for an excessive + * amount and destroy system throughput? */ - usleep(delay); + if (delay > CONFIG_USEC_PER_TICK) + { + usleep(delay - CONFIG_USEC_PER_TICK); + } } } else diff --git a/arch/arm/src/stm32/stm32_otghshost.c b/arch/arm/src/stm32/stm32_otghshost.c index 17023088b6..1836808764 100644 --- a/arch/arm/src/stm32/stm32_otghshost.c +++ b/arch/arm/src/stm32/stm32_otghshost.c @@ -1957,14 +1957,25 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx, delay = 1000; } - /* Wait for the next polling interval. + /* Wait for the next polling interval. For interrupt and + * isochronous endpoints, this is necessaryto assure the + * polling interval. It is used in other cases only to + * prevent the polling from consuming too much CPU bandwith. * - * REVISIT: This delay could require more resolution than - * is provided by the system timer. In that case, the - * delay could be significantly longer than required. + * Small delays could require more resolution than is provided + * by the system timer. For example, if the system timer + * resolution is 10MS, then usleep(1000) will actually request + * a delay 20MS (due to both quantization and rounding). + * + * REVISIT: So which is better? To ignore tiny delays and + * hog the system bandwidth? Or to wait for an excessive + * amount and destroy system throughput? */ - usleep(delay); + if (delay > CONFIG_USEC_PER_TICK) + { + usleep(delay - CONFIG_USEC_PER_TICK); + } } } else diff --git a/arch/arm/src/stm32f7/stm32_otghost.c b/arch/arm/src/stm32f7/stm32_otghost.c index f0307be640..92fc2bc7d0 100644 --- a/arch/arm/src/stm32f7/stm32_otghost.c +++ b/arch/arm/src/stm32f7/stm32_otghost.c @@ -1951,14 +1951,25 @@ static ssize_t stm32_in_transfer(FAR struct stm32_usbhost_s *priv, int chidx, delay = 1000; } - /* Wait for the next polling interval. + /* Wait for the next polling interval. For interrupt and + * isochronous endpoints, this is necessaryto assure the + * polling interval. It is used in other cases only to + * prevent the polling from consuming too much CPU bandwith. * - * REVISIT: This delay could require more resolution than - * is provided by the system timer. In that case, the - * delay could be significantly longer than required. + * Small delays could require more resolution than is provided + * by the system timer. For example, if the system timer + * resolution is 10MS, then usleep(1000) will actually request + * a delay 20MS (due to both quantization and rounding). + * + * REVISIT: So which is better? To ignore tiny delays and + * hog the system bandwidth? Or to wait for an excessive + * amount and destroy system throughput? */ - usleep(delay); + if (delay > CONFIG_USEC_PER_TICK) + { + usleep(delay - CONFIG_USEC_PER_TICK); + } } } else