On Wed, Jan 3, 2018 at 11:38 AM, Benjamin Beckmeyer
<beckmeyer.b@xxxxxxxxx> 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...)
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;
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
