MMC flash is very slow since 4.14 - "mmc: Delete bounce buffer handling" was the problem

Commit Message

Linus Walleij Jan. 3, 2018, 2:45 p.m. UTC

On Wed, Jan 3, 2018 at 11:38 AM, Benjamin Beckmeyer
<[e-mail]> wrote:

>> Can you confirm that you see "using PIO" in your dmesg kernel log?
>> Or are you just using "DMA"? (i.e. SDMA, see below)
>
> #dmesg | grep SDHCI
> [    1.302225] sdhci-pltfm: SDHCI platform and OF driver helper
> [    1.370016] mmc0: SDHCI controller on 53fb4000.esdhc [53fb4000.esdhc] using DMA
> [    1.450436] mmc1: SDHCI controller on 53fb8000.esdhc [53fb8000.esdhc] using DMA

Aha it is the SDMA on the i.MX that is benefiting from the bounce buffer.
So it is likely collecting a lot of small reads/writes into a bigger buffer and
that is why it becomes (a lot) faster.

>> Can we try the easy solutions first, what about testing something like this?
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
(...)
> Because we are using DMA I don't think that solution will do anything.

No you're right.

>> If you're using SDMA, maybe, just maybe, PIO is actually faster, because
>> it avoids the buffer copying that happens just in order to put things nicely
>> in order for SDMA.
>
> I just did a quick test and commented out the else part in the above code
> snippet to use PIO but after that try the devices doesn't boot anymore.
>
> Did I miss something?

Hm can you try just something like this, making the device fall back
to PIO? (Verify with boot messages...)

If that doesn't work I guess the device *must* use DMA.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Benjamin Beckmeyer Jan. 3, 2018, 3:32 p.m. UTC | #1

> Hm can you try just something like this, making the device fall back
> to PIO? (Verify with boot messages...)

I verified the fall back already with my last post. In the bootlog the 
SDHCI controller was explicity using PIO, but then it hangs.
Sorry maybe i wasn't clear enough about that. 

But I tested your idea against the mainline kernel and had the same results.

mmc0: SDHCI controller on 53fb4000.esdhc [53fb4000.esdhc] using PIO
sdhci-esdhc-imx 53fb8000.esdhc: Got CD GPIO
sdhci-esdhc-imx 53fb8000.esdhc: Got WP GPIO
mmc1: SDHCI controller on 53fb8000.esdhc [53fb8000.esdhc] using PIO
random: crng init done


But it hangs while booting. The lines above are the last output on the serial console.

So, for now, I guess the device needs the DMA.

Kinds,
Benjamin Beckmeyer
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Linus Walleij Jan. 3, 2018, 5:28 p.m. UTC | #2

On Wed, Jan 3, 2018 at 4:32 PM, Benjamin Beckmeyer
<[e-mail]> wrote:

> But it hangs while booting. The lines above are the last output on the serial console.
>
> So, for now, I guess the device needs the DMA.

Yeah seems like so... :/

So we need to get a bounce buffer back for bugged SDHI devices.

I see two options:

1. Put the bounce buffer into the SDHCI host (this is the only driver
    that seems to have any need for it).

2. Manage it centrally. (Like we did before, or in the block layer.)

Notice that the block core has bounce buffer support. However there,
it is used to bounce highmem buffers to lowmem buffers because of
hardware limitations.

The bounce buffers we use with SDMA are only
for copying the SG list fragments into a continous buffer so that we
do not need to shoot off a lot of individual small DMA jobs.

I hope everyone is on the same page here, that this is where
the speedup comes from?

I guess I can try to open code some stuff into the SDHCI driver
for the SDMA case (I guess it should be for that case only.)
Lemme see what I can hack up!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Benjamin Beckmeyer Jan. 4, 2018, 9:02 a.m. UTC | #3

>Lemme see what I can hack up!  

Let me know, when I can help you in any way. I can test your solution for this 
architecture and the driver.

Kind regards,
Benjamin Beckmeyer
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 85140c9af581..f1d2e2f016f8 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1299,7 +1299,7 @@  static int sdhci_esdhc_imx_probe(struct
platform_device *pdev)
                                        esdhc_executing_tuning;

        if (imx_data->socdata->flags & ESDHC_FLAG_ERR004536)
-               host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+               host->quirks |= SDHCI_QUIRK_BROKEN_ADMA |
SDHCI_QUIRK_BROKEN_DMA;