Skip to contentSkip to conversation

sunxi: improve throughput in the sunxi_mmc driver

PATCH New Maxime Ripard 5 participants 13 messages Mar 21, 2018 – Apr 25, 2018

Subsystems (2)
MMC, SD and SDIO Arm/Allwinner sunXi SoC support
lore
Share & tools
lore

Maxime Ripard

author
#0 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>
---
 drivers/mmc/sunxi_mmc.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)
drivers/mmc/sunxi_mmc.c +16 -11
index 4edb4be46c81..d36c1689e7b1 100644
@@ -187,15 +187,16 @@ static int mmc_update_clk(struct sunxi_mmc_priv *priv)
 {
 	unsigned int cmd;
 	unsigned timeout_msecs = 2000;
+	unsigned long start = get_timer(0);
 
 	cmd = SUNXI_MMC_CMD_START |
 	      SUNXI_MMC_CMD_UPCLK_ONLY |
 	      SUNXI_MMC_CMD_WAIT_PRE_OVER;
+
 	writel(cmd, &priv->reg->cmd);
 	while (readl(&priv->reg->cmd) & SUNXI_MMC_CMD_START) {
-		if (!timeout_msecs--)
+		if (get_timer(start) > timeout_msecs)
 			return -1;
-		udelay(1000);
 	}
 
 	/* clock update sets various irq status bits, clear these */

@@ -276,18 +277,21 @@ static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv *priv, struct mmc *mmc,
 	unsigned i;
 	unsigned *buff = (unsigned int *)(reading ? data->dest : data->src);
 	unsigned byte_cnt = data->blocksize * data->blocks;
-	unsigned timeout_usecs = (byte_cnt >> 8) * 1000;
-	if (timeout_usecs < 2000000)
-		timeout_usecs = 2000000;
+	unsigned timeout_msecs = byte_cnt >> 8;
+	unsigned long  start;
+
+	if (timeout_msecs < 2000)
+		timeout_msecs = 2000;
 
 	/* Always read / write data through the CPU */
 	setbits_le32(&priv->reg->gctrl, SUNXI_MMC_GCTRL_ACCESS_BY_AHB);
 
+	start = get_timer(0);
+
 	for (i = 0; i < (byte_cnt >> 2); i++) {
 		while (readl(&priv->reg->status) & status_bit) {
-			if (!timeout_usecs--)
+			if (get_timer(start) > timeout_msecs)
 				return -1;
-			udelay(1);
 		}
 
 		if (reading)

@@ -303,16 +307,16 @@ static int mmc_rint_wait(struct sunxi_mmc_priv *priv, struct mmc *mmc,
 			 uint timeout_msecs, uint done_bit, const char *what)
 {
 	unsigned int status;
+	unsigned long start = get_timer(0);
 
 	do {
 		status = readl(&priv->reg->rint);
-		if (!timeout_msecs-- ||
+		if ((get_timer(start) > timeout_msecs) ||
 		    (status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT)) {
 			debug("%s timeout %x\n", what,
 			      status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT);
 			return -ETIMEDOUT;
 		}
-		udelay(1000);
 	} while (!(status & done_bit));
 
 	return 0;

@@ -404,15 +408,16 @@ static int sunxi_mmc_send_cmd_common(struct sunxi_mmc_priv *priv,
 	}
 
 	if (cmd->resp_type & MMC_RSP_BUSY) {
+		unsigned long start = get_timer(0);
 		timeout_msecs = 2000;
+
 		do {
 			status = readl(&priv->reg->status);
-			if (!timeout_msecs--) {
+			if (get_timer(start) > timeout_msecs) {
 				debug("busy timeout\n");
 				error = -ETIMEDOUT;
 				goto out;
 			}
-			udelay(1000);
 		} while (status & SUNXI_MMC_STATUS_CARD_DATA_BUSY);
 	}
Signature · 1 line
2.14.3
#1 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Hello,

Quoted 13 lines · On Wed, 21 Mar 2018 12:18:58 +0100 Maxime Ripard <[email protected]>…

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 5 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>
Tested-by Mylène Josserand <[email protected]>

Thanks,

Signature · 3 lines
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
#2 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

In reply to Maxime Ripard
Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 2 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Fyi: I've seen significant improvement, but not 10x on A64 (bananpi-m64) with read

Before this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
reading Image
16310784 bytes read in 821 ms (18.9 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 1109 ms (14 MiB/s)

After this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
16310784 bytes read in 784 ms (19.8 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 793 ms (19.6 MiB/s)

Jagan.

author
#3 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Quoted 38 lines · Jagan Teki
Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 2 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Fyi: I've seen significant improvement, but not 10x on A64 (bananpi-m64) with read

Before this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
reading Image
16310784 bytes read in 821 ms (18.9 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 1109 ms (14 MiB/s)

After this change:

Quoted 10 lines

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
16310784 bytes read in 784 ms (19.8 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 793 ms (19.6 MiB/s)

Yeah, the smaller the file is, the bigger the gain is. Since you have an almost twice bigger file, the gains are probably just noise at that point and the bottleneck starts to be your MMC.

Maxime

Signature · 10 lines
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180404/14c09f53/attachment.sig>
#4 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Quoted 50 lines · Maxime Ripard
Quoted 38 lines · Jagan Teki
Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 2 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Fyi: I've seen significant improvement, but not 10x on A64 (bananpi-m64) with read

Before this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
reading Image
16310784 bytes read in 821 ms (18.9 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 1109 ms (14 MiB/s)

After this change:

Quoted 10 lines

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
16310784 bytes read in 784 ms (19.8 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 793 ms (19.6 MiB/s)

Quoted 3 lines

Yeah, the smaller the file is, the bigger the gain is. Since you have an almost twice bigger file, the gains are probably just noise at that point and the bottleneck starts to be your MMC.

Acked-by Jagan Teki <[email protected]>
author
#5 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Hi Jagan,

Quoted 52 lines · Jagan Teki
Quoted 50 lines · Maxime Ripard
Quoted 48 lines · Jagan Teki
Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 2 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Fyi: I've seen significant improvement, but not 10x on A64 (bananpi-m64) with read

Before this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
reading Image
16310784 bytes read in 821 ms (18.9 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 1109 ms (14 MiB/s)

After this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
16310784 bytes read in 784 ms (19.8 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 793 ms (19.6 MiB/s)

Quoted 5 lines
Quoted 3 lines

Yeah, the smaller the file is, the bigger the gain is. Since you have an almost twice bigger file, the gains are probably just noise at that point and the bottleneck starts to be your MMC.

Acked-by Jagan Teki <[email protected]>

Jaehoon doesn't seem to reply at all, can we merge this through the sunxi tree?

Thanks!
Maxime

Signature · 3 lines
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#6 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Quoted 55 lines · Maxime Ripard

Hi Jagan,

Quoted 52 lines · Jagan Teki
Quoted 50 lines · Maxime Ripard
Quoted 48 lines · Jagan Teki
Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 2 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Fyi: I've seen significant improvement, but not 10x on A64 (bananpi-m64) with read

Before this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
reading Image
16310784 bytes read in 821 ms (18.9 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 1109 ms (14 MiB/s)

After this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
16310784 bytes read in 784 ms (19.8 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 793 ms (19.6 MiB/s)

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Yeah, the smaller the file is, the bigger the gain is. Since you have an almost twice bigger file, the gains are probably just noise at that point and the bottleneck starts to be your MMC.

Acked-by Jagan Teki <[email protected]>

Jaehoon doesn't seem to reply at all, can we merge this through the sunxi tree?

Yes.

Reviewed-by Tom Rini <[email protected]>
Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180424/6b0495d6/attachment.sig>
#7 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Quoted 56 lines · Tom Rini
Quoted 55 lines · Maxime Ripard

Hi Jagan,

Quoted 52 lines · Jagan Teki
Quoted 50 lines · Maxime Ripard
Quoted 48 lines · Jagan Teki
Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 2 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Fyi: I've seen significant improvement, but not 10x on A64 (bananpi-m64) with read

Before this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
reading Image
16310784 bytes read in 821 ms (18.9 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 1109 ms (14 MiB/s)

After this change:

=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> fatload mmc 0:1 $kernel_addr_r Image
16310784 bytes read in 784 ms (19.8 MiB/s)
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> ext4load mmc 1:1 $kernel_addr_r Image
16310784 bytes read in 793 ms (19.6 MiB/s)

Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Yeah, the smaller the file is, the bigger the gain is. Since you have an almost twice bigger file, the gains are probably just noise at that point and the bottleneck starts to be your MMC.

Acked-by Jagan Teki <[email protected]>

Jaehoon doesn't seem to reply at all, can we merge this through the sunxi tree?

Applied to u-boot-sunxi/master

author
#8 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

In reply to Maxime Ripard

Hi Jaehoon,

Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 5 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>

Any chance we can merge this for the next release?

Thanks!
Maxime

Signature · 3 lines
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
author
#9 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Quoted 16 lines · Maxime Ripard

Hi Jaehoon,

Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 7 lines
Quoted 5 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>

Any chance we can merge this for the next release?

Ping?

Maxime

Signature · 10 lines
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180416/6b5e6fc3/attachment.sig>
#10 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Hi

Quoted 20 lines · Maxime Ripard
Quoted 19 lines · Maxime Ripard

Hi Jaehoon,

Quoted 16 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>

Any chance we can merge this for the next release?

Ping?

Just curios but what is the result if %s/udelay(1000)/udelay(1)/g in the driver

Michael

Quoted 12 lines

Maxime

--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Signature · 4 lines
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |
author
#11 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Quoted 27 lines · Michael Nazzareno Trimarchi

Hi

Quoted 23 lines · Maxime Ripard
Quoted 22 lines · Maxime Ripard

Hi Jaehoon,

Quoted 18 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>
Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Any chance we can merge this for the next release?

Ping?

Just curios but what is the result if %s/udelay(1000)/udelay(1)/g in the driver

This will probably speed up the transfer as well, but we don't need that udelay in the first place. We don't have any application or OS to be nice to, so we can just busy loop in order to achieve the higher throughput. Or am I missing something?

Maxime

Signature · 3 lines
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#12 lore raw

PATCH 1/1 sunxi: improve throughput in the sunxi_mmc driver

Hi

Quoted 33 lines · Maxime Ripard
Quoted 32 lines · Michael Nazzareno Trimarchi

Hi

Quoted 27 lines · Maxime Ripard
Quoted 16 lines · Maxime Ripard

Hi Jaehoon,

Quoted 13 lines · Maxime Ripard

From: Philipp Tomsich <[email protected]>

Throughput tests have shown the sunxi_mmc driver to take over 10s to read 10MB from a fast eMMC device due to excessive delays in polling loops.

This commit restructures the main polling loops to use get_timer(...) to determine whether a (millisecond) timeout has expired. We choose not to use the wait_bit function, as we don't need interruptability with ctrl-c and have at least one case where two bits (one for an error condition and another one for completion) need to be read and using wait_bit would have not added to the clarity.

Quoted 7 lines
Quoted 5 lines

The observed speedup in testing on a A31 is greater than 10x (e.g. a 10MB write decreases from 9.302s to 0.884s).

Signed-off-by Philipp Tomsich <[email protected]>
Signed-off-by Maxime Ripard <[email protected]>

Any chance we can merge this for the next release?

Ping?

Quoted 8 lines
Quoted 2 lines

Just curios but what is the result if %s/udelay(1000)/udelay(1)/g in the driver

This will probably speed up the transfer as well, but we don't need that udelay in the first place. We don't have any application or OS to be nice to, so we can just busy loop in order to achieve the higher throughput. Or am I missing something?

One is to try to have less code change and second was to ping in another way to be included

Michael

Quoted 6 lines

Maxime

--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Signature · 4 lines
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |