From patchwork Mon Jan 22 08:16:10 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 10177459 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 CE63C60224 for ; Mon, 22 Jan 2018 08:16:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BE53927CAF for ; Mon, 22 Jan 2018 08:16:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B20BB27EE2; Mon, 22 Jan 2018 08:16:14 +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 112F227CAF for ; Mon, 22 Jan 2018 08:16:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751057AbeAVIQM (ORCPT ); Mon, 22 Jan 2018 03:16:12 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:42286 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751021AbeAVIQM (ORCPT ); Mon, 22 Jan 2018 03:16:12 -0500 Received: by mail-io0-f193.google.com with SMTP id 25so8584590ioj.9 for ; Mon, 22 Jan 2018 00:16:11 -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=cEIbAVqh/wwNCKrGouPzDYLcTxNWaovIqwVQt/5kdmw=; b=M1oZ2bx9/Um/VdPds+8jVWGx1T7/ALSW1F9skEMd+h8QqXq+GkaRj5hF8rNHGajdx1 jOmr5LHS4hd8qdPeyqodxkLl3/gvlVSvuFffmkCsTYDo/d9RztnGcPtH/QLsPDy/rLw8 tPXobbpzIYRWaNUiwpGB2jzpckHhJKnLjyisM= 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=cEIbAVqh/wwNCKrGouPzDYLcTxNWaovIqwVQt/5kdmw=; b=AdUj6PXek23lPReFfLX0Lh+kpu1er1/AMcPEgUznoK9tJGJ+A7/EwHRCpenL77pNO4 5zmoHUaE/Glb39/xjV8mB1bT+RsydR2bZaC6daB+9LGsKyM/KQY5wjq9vWiCrC6ZrV/f 6SPofb0AkNn6MVVZM/E4XHrlKjKWF37isZydUEllnDgfEUV5FsrYyirQpqVFYjx5YSmm 05iBQnS8O/Ai4aNO3BqBFIZuGV6KXw7+tFvbch8CHD5f/ovwQzhzEkPwViIk3ikHU9v9 EsABYCsj0lEsihREcvha0Vp11ib7Y2/3ehHs8SJMshZdaLRFre3Xts6uWenFtOIaZiYz xb2g== X-Gm-Message-State: AKwxytctvDyU5lp8DJ6I5AyjxbYRMltZ8Fjy26LMA4wx2zqTHEBRqTk1 EptFovj22YDT54CzAn+RduNfkpk59/o+aOqluG9BYg== X-Google-Smtp-Source: AH8x225ODZU7JcbpXRyODyCcK2xrlb8fbmolAb/U/N6W+1zG6RDr+3XLf8bN9qhgiCYfFBdNo5aS2tMrGzD2bvg99Iw= X-Received: by 10.107.104.17 with SMTP id d17mr6908257ioc.138.1516608971505; Mon, 22 Jan 2018 00:16:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.102.131 with HTTP; Mon, 22 Jan 2018 00:16:10 -0800 (PST) In-Reply-To: References: <20180119145303.4097-1-linus.walleij@linaro.org> From: Linus Walleij Date: Mon, 22 Jan 2018 09:16:10 +0100 Message-ID: Subject: Re: [PATCH v6] RFT: mmc: sdhci: Implement an SDHCI-specific bounce buffer To: Benjamin Beckmeyer Cc: linux-mmc , Ulf Hansson , Adrian Hunter , Pierre Ossman , =?UTF-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= , Fabio Estevam , stable 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 Mon, Jan 22, 2018 at 7:18 AM, Benjamin Beckmeyer wrote: > I tested it a few moments ago and to make it short: it doesn't work. Annoying ... since the i.MX and x86 PCI version so clearly differs here I'm left to trial and error over the mailing list. > mmc1 bounce up to 128 segments into one, max segment size 65536 bytes > mmc1: SDHCI controller on 53fb8000.esdhc [53fb8000.esdhc] using DMA Could it be that this SDMA has this problem of not being able to send things aligned on even 64K pages? (Off-by-one error in the hardware.) Could you try this on top of the patch? * than our segment size, else hammer down the maximum The code should report that it bounces 127 segments into 1 instead. 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.c b/drivers/mmc/host/sdhci.c index 25b5e598ee6d..6b436f0e0925 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3323,7 +3323,7 @@ static int sdhci_allocate_bounce_buffer(struct sdhci_host *host) * has diminishing returns, this is probably because SD/MMC * cards are usually optimized to handle this size of requests. */ - bounce_size = SZ_64K; + bounce_size = SZ_64K-1; /* * Adjust downwards to maximum request size if this is less