[PATCH v2] Staging: dgnc: dgnc_*.c: Use usleep_range over udelay to improve coalescing processor wakeups

[PATCH v2] Staging: dgnc: dgnc_*.c: Use usleep_range over udelay to improve coalescing processor wakeups

[Shiva Kerdel]

In most cases, usleep_range is better than udelay, as the precise wakeup
from udelay is unnecessary.

usleep_range gives a much better chance of coalescing processor wakeups.

Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
---
Changes for v2:
    - Squashed the two commits to one patch.

 drivers/staging/dgnc/dgnc_cls.c |  6 +++---
 drivers/staging/dgnc/dgnc_neo.c | 10 +++++-----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index c20ffdd..6607243a 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -409,7 +409,7 @@ static void cls_assert_modem_signals(struct channel_t *ch)
 	writeb(out, &ch->ch_cls_uart->mcr);
 
 	/* Give time for the UART to actually drop the signals */
-	udelay(10);
+	usleep_range(10, 20);
 }
 
 static void cls_copy_data_from_queue_to_uart(struct channel_t *ch)
@@ -631,7 +631,7 @@ static void cls_flush_uart_read(struct channel_t *ch)
 	 * Presumably, this is a bug in this UART.
 	 */
 
-	udelay(10);
+	usleep_range(10, 20);
 }
 
 /*
@@ -1096,7 +1096,7 @@ static void cls_uart_init(struct channel_t *ch)
 
 	writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
 	       &ch->ch_cls_uart->isr_fcr);
-	udelay(10);
+	usleep_range(10, 20);
 
 	ch->ch_flags |= (CH_FIFO_ENABLED | CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
 
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 3eefefe..20bc271 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1352,7 +1352,7 @@ static void neo_flush_uart_write(struct channel_t *ch)
 		 */
 		tmp = readb(&ch->ch_neo_uart->isr_fcr);
 		if (tmp & 4)
-			udelay(10);
+			usleep_range(10, 20);
 		else
 			break;
 	}
@@ -1384,7 +1384,7 @@ static void neo_flush_uart_read(struct channel_t *ch)
 		 */
 		tmp = readb(&ch->ch_neo_uart->isr_fcr);
 		if (tmp & 2)
-			udelay(10);
+			usleep_range(10, 20);
 		else
 			break;
 	}
@@ -1616,7 +1616,7 @@ static void neo_assert_modem_signals(struct channel_t *ch)
 	neo_pci_posting_flush(ch->ch_bd);
 
 	/* Give time for the UART to actually raise/drop the signals */
-	udelay(10);
+	usleep_range(10, 20);
 }
 
 static void neo_send_start_character(struct channel_t *ch)
@@ -1628,7 +1628,7 @@ static void neo_send_start_character(struct channel_t *ch)
 		ch->ch_xon_sends++;
 		writeb(ch->ch_startc, &ch->ch_neo_uart->txrx);
 		neo_pci_posting_flush(ch->ch_bd);
-		udelay(10);
+		usleep_range(10, 20);
 	}
 }
 
@@ -1641,7 +1641,7 @@ static void neo_send_stop_character(struct channel_t *ch)
 		ch->ch_xoff_sends++;
 		writeb(ch->ch_stopc, &ch->ch_neo_uart->txrx);
 		neo_pci_posting_flush(ch->ch_bd);
-		udelay(10);
+		usleep_range(10, 20);
 	}
 }
 
-- 
2.10.2

Re: [PATCH v2] Staging: dgnc: dgnc_*.c: Use usleep_range over udelay to improve coalescing processor wakeups

[Greg KH]

On Tue, Dec 06, 2016 at 09:59:58AM +0100, Shiva Kerdel wrote:
> In most cases, usleep_range is better than udelay, as the precise wakeup
> from udelay is unnecessary.

But, udelay does something different than usleep, are you sure you
should be giving up the cpu at this point in time?

Are you sure you are even in a function that is allowed to sleep?  I
don't think that is the case for all of these at all, sorry, unless you
have the hardware to test this change, I can't take it.

greg k-h

Re: [PATCH v2] Staging: dgnc: dgnc_*.c: Use usleep_range over udelay to improve coalescing processor wakeups

[Shiva Kerdel]

> On Tue, Dec 06, 2016 at 09:59:58AM +0100, Shiva Kerdel wrote:
>> In most cases, usleep_range is better than udelay, as the precise wakeup
>> from udelay is unnecessary.
> But, udelay does something different than usleep, are you sure you
> should be giving up the cpu at this point in time?
>
> Are you sure you are even in a function that is allowed to sleep?  I
> don't think that is the case for all of these at all, sorry, unless you
> have the hardware to test this change, I can't take it.
>
> greg k-h
I wasn't aware of this, thank you for pointing out.
Since I don't have this hardware, I'm unable to test the changes.

Shiva Kerdel