From patchwork Tue Nov 21 15:08:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 10068423 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 CFD58602B7 for ; Tue, 21 Nov 2017 15:08:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C18962973B for ; Tue, 21 Nov 2017 15:08:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B5C4129755; Tue, 21 Nov 2017 15:08:47 +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 3E40E29751 for ; Tue, 21 Nov 2017 15:08:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751191AbdKUPIq (ORCPT ); Tue, 21 Nov 2017 10:08:46 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:42983 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187AbdKUPIp (ORCPT ); Tue, 21 Nov 2017 10:08:45 -0500 Received: by mail-it0-f68.google.com with SMTP id n134so2345780itg.1 for ; Tue, 21 Nov 2017 07:08:44 -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=/5ADKqCRHzhrGMl8mBV3ExLsuJuFyg74tQ3gQCplMuY=; b=D67ZtkrfACZP3fV65ZtU2AI2TJuH3vRewgu8tMMHliRl33gESLkVvKRrq9uKUSYw0r kfm7mAZgQnHN4B5DtlwqZqOi4siTdbKh72MrWkaMZvKH7XXBMOHlrFoC0rNzalOhv18L p9Vhveo88Cv/4NARiMitnAztIHzfn2/4l/UnM= 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=/5ADKqCRHzhrGMl8mBV3ExLsuJuFyg74tQ3gQCplMuY=; b=fD2RHR3tay3kGiGo5aalqPeccwRidRQMAsj+CNNIavr8MVpHOyJBMTu8guJXGLWb48 18r4P3rA8vowyk6EfY9Ltcz/qQTh8xGRpSIMvDWpUk4rh3z49wstnuJjYzr4sYLE6YF5 SJ8T6sYDjSiHS7CfH0CdN41Z0wfxnLsCj35JRotkvkl6xEE8/AC8jVFT3U02u9HH4GJS muIi5Mns2WQWu8k/dST7JmnTjEwP5LlhGP0yo8XdrxA5VTj+th7KO6CEmPnAWFowYahk znVzurYjcQk/aKR+Vrg2mpkJTnitzyXNj37w5P4N9MxhR5DHg+Kx2g9S44/GQTGd8mOc Wt0w== X-Gm-Message-State: AJaThX4gBJ1dUI9qwDTbc2wrp7IaBpGIKlwcZftf7wzReN91mY/dA2EK /4yxs2H01vnItQqegJ0lrrAgqNwGzDiPD5cslCBiMw== X-Google-Smtp-Source: AGs4zMa56mxTuqLBSiwhMK11HEHxINroRYEt6ZbDHdeyZHlJazGP5xbCQJA063283E2PewxFQKpWw/TYV477VudVJxI= X-Received: by 10.36.236.5 with SMTP id g5mr2241679ith.73.1511276924307; Tue, 21 Nov 2017 07:08:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.86.149 with HTTP; Tue, 21 Nov 2017 07:08:43 -0800 (PST) In-Reply-To: <2248b8b6-a80f-52ef-943f-54c1351d5a36@suse.cz> References: <1507361610-31577-1-git-send-email-ulf.hansson@linaro.org> <2248b8b6-a80f-52ef-943f-54c1351d5a36@suse.cz> From: Ulf Hansson Date: Tue, 21 Nov 2017 16:08:43 +0100 Message-ID: Subject: Re: sdhci broke in 4.14 [was: MMC fixes for v.4.14-rc4] To: Jiri Slaby Cc: Linus , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jaehoon Chung , Adrian Hunter , Linus Walleij , Yoshihiro Shimoda , Geert Uytterhoeven , Konrad Rzeszutek Wilk 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 + Yoshihiro, Geert, Konrad On 20 November 2017 at 14:12, Jiri Slaby wrote: > On 10/07/2017, 09:33 AM, Ulf Hansson wrote: >> Here's a PR with a couple of MMC fixes intended for v4.14-rc4. Details about the >> highlights are as usual found in the signed tag. > ... >> ---------------------------------------------------------------- >> MMC core: >> - Delete bounce buffer handling: >> This change fixes a problem related to how bounce buffers are being >> allocated. However, instead of trying to fix that, let's just remove >> the mmc bounce buffer code altogether, as it has practically no use. > > That is completely false, this breaks my sd card reader in 4.14 so that > the system is mostly unusable during transfers -- it is stuttering: > sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 311296 bytes) > sdhci-pci 0000:02:00.0: DMA: Out of SW-IOMMU space for 311296 bytes > sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 311296 bytes) > sdhci-pci 0000:02:00.0: DMA: Out of SW-IOMMU space for 311296 bytes Thanks for reporting! This is a similar problem that was reported for the tmio mmc driver, which got fixed in commit e90e8da72ad6 ("mmc: tmio: fix swiotlb buffer is full"). It seems like we need something along those lines for the sdhci-pci case as well. I cooked a patch, perhaps you have some time for test? I also looped in the folkz involved in the fix for tmio mmc, let's see if they can comment. My worries is only that there seems to be yet some additional cases that may set mmc->max_segs = 1, so perhaps we should actually try to deal with these case from mmc_add_host() instead. Anyway, let's try this out first. Subject: [PATCH] mmc: sdhci: Fix bounce buffer overflow Signed-off-by: Ulf Hansson --- drivers/mmc/host/sdhci.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 2f14334..e9290a3 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -3651,22 +3652,29 @@ int sdhci_setup_host(struct sdhci_host *host) spin_lock_init(&host->lock); /* + * Maximum number of sectors in one transfer. Limited by SDMA boundary + * size (512KiB). Note some tuning modes impose a 4MiB limit, but this + * is less anyway. + */ + mmc->max_req_size = 524288; + + /* * Maximum number of segments. Depends on if the hardware * can do scatter/gather or not. */ - if (host->flags & SDHCI_USE_ADMA) + if (host->flags & SDHCI_USE_ADMA) { mmc->max_segs = SDHCI_MAX_SEGS; - else if (host->flags & SDHCI_USE_SDMA) + } else if (host->flags & SDHCI_USE_SDMA) { mmc->max_segs = 1; - else /* PIO */ + if (swiotlb_max_segment()) { + unsigned int max_req_size = (1 << IO_TLB_SHIFT) * + IO_TLB_SEGSIZE; + mmc->max_req_size = min(mmc->max_req_size, + max_req_size); + } + } else { /* PIO */ mmc->max_segs = SDHCI_MAX_SEGS; - - /* - * Maximum number of sectors in one transfer. Limited by SDMA boundary - * size (512KiB). Note some tuning modes impose a 4MiB limit, but this - * is less anyway. - */ - mmc->max_req_size = 524288; + } /* * Maximum segment size. Could be one segment with the maximum number