[U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

[Tom Rini <trini@konsulko.com>]

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.ripard@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.ripard@bootlin.com> wrote:
> > >> > From: Philipp Tomsich <philipp.tomsich@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 <jagan@openedev.com>
> 
> Jaehoon doesn't seem to reply at all, can we merge this through the
> sunxi tree?

Yes.

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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>