From patchwork Wed Jan 3 14:45:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 10142467 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5D0F36035E for ; Wed, 3 Jan 2018 14:45:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4A7532901E for ; Wed, 3 Jan 2018 14:45:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3E9C129118; Wed, 3 Jan 2018 14:45:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 870FD2901E for ; Wed, 3 Jan 2018 14:45:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751966AbeACOp1 (ORCPT ); Wed, 3 Jan 2018 09:45:27 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:46098 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbeACOp0 (ORCPT ); Wed, 3 Jan 2018 09:45:26 -0500 Received: by mail-it0-f66.google.com with SMTP id c16so1925738itc.5 for ; Wed, 03 Jan 2018 06:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f/lPAbeS9fMvFLAirA87Bhchjb4F+e4WhD4WZ1hPNgs=; b=IrTXXMBg3YG8PjWcafiZlUD3gf1DpxH6UOCn3ac+pZkl5N2HUF0PuMgA2rGOg6/ndy OgVnm52/Aw4/I38npiAFF3yFWqjMRcs1fmwWU+6Wj3yy+yOfII28i5XJzW6NNilT8lir y5/FMpRp7DavTQDUBSbTr9opO6ZX+YHpXGH18= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f/lPAbeS9fMvFLAirA87Bhchjb4F+e4WhD4WZ1hPNgs=; b=kdyi4RCL6pvUiD01/aeRlGVDzWlWBHtbLQcBvjbcp8h2+4l1ioHp76Ot+SQGGv4HDU /ne07KkqZRDSXsy9qhxovuLEIsAuLOIc23dpR6nhslvwevwflHfTqbNVkK+4EfBszvUt 6cH/4SPUnQo521Lb6L1XmkrawAmK8xWJZEO6WXQg0WLwEn1ju02786rYIb4ew669b3kc VNV15yRoBBVat8VA+I792PG3J4ilGsxH+mSD60LfT4aUllfpZghdhgChhR2UHL/REI75 wk9+j99UVHKpW79gWGP0jrjuT/hF1iWV1L6ufcHJ6KGt9yzSKD9V1sCoGrWuXxcrY513 yT0w== X-Gm-Message-State: AKGB3mIJE2kpn+H/oDRP704h9XYtsHD+r4cvyNMetFy+f0pnZ/qAs5a4 iQ/sQfdQpWBgYAYxdn/StEMEoDTygDFg5Bcfc5sDMyTHvsQ= X-Google-Smtp-Source: ACJfBoukgyvZ23Msw2m2XNMwbKeVgJBpScQjL5qCUbYjSXH+apSNfSTQKj6qAAJzK32tEeFSG1JKJIb2AFRN5xrxAlc= X-Received: by 10.36.115.79 with SMTP id y76mr2076811itb.144.1514990726060; Wed, 03 Jan 2018 06:45:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.87.84 with HTTP; Wed, 3 Jan 2018 06:45:25 -0800 (PST) In-Reply-To: References: From: Linus Walleij Date: Wed, 3 Jan 2018 15:45:25 +0100 Message-ID: Subject: Re: MMC flash is very slow since 4.14 - "mmc: Delete bounce buffer handling" was the problem To: Benjamin Beckmeyer Cc: Ulf Hansson , linux-mmc , Pierre Ossman Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Jan 3, 2018 at 11:38 AM, Benjamin Beckmeyer 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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;