On Wed, Apr 25, 2018 at 1:46 AM, Tom Rini <tr...@konsulko.com> wrote: > On Tue, Apr 24, 2018 at 09:57:58PM +0200, Maxime Ripard wrote: >> Hi Jagan, >> >> On Fri, Apr 06, 2018 at 11:36:59AM +0530, Jagan Teki wrote: >> > On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard >> > <maxime.rip...@bootlin.com> wrote: >> > > On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote: >> > >> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard >> > >> <maxime.rip...@bootlin.com> wrote: >> > >> > From: Philipp Tomsich <philipp.toms...@theobroma-systems.com> >> > >> > >> > >> > 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). >> > >> >> > >> 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) >> > > >> > > 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 <ja...@openedev.com> >> >> Jaehoon doesn't seem to reply at all, can we merge this through the >> sunxi tree?
Applied to u-boot-sunxi/master _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
