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

Maxime Ripard
2018-04-20T20:10:45Z

On Mon, Apr 16, 2018 at 10:37:11PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Mon, Apr 16, 2018 at 9:55 PM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > On Fri, Apr 06, 2018 at 07:54:47AM +0200, Maxime Ripard wrote:
> >> Hi Jaehoon,
> >>
> >> On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard 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).
> >> >
> >> > Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >>
> >> 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

--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering