From patchwork Tue Dec 13 19:20:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gwendal Grignou X-Patchwork-Id: 9473003 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 3FE4060476 for ; Tue, 13 Dec 2016 19:21:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4C31928657 for ; Tue, 13 Dec 2016 19:21:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3EAC62867B; Tue, 13 Dec 2016 19:21:53 +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 B6DE728657 for ; Tue, 13 Dec 2016 19:21:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933746AbcLMTVP (ORCPT ); Tue, 13 Dec 2016 14:21:15 -0500 Received: from mail-pg0-f46.google.com ([74.125.83.46]:34588 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752826AbcLMTUa (ORCPT ); Tue, 13 Dec 2016 14:20:30 -0500 Received: by mail-pg0-f46.google.com with SMTP id x23so50696775pgx.1 for ; Tue, 13 Dec 2016 11:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:cc:subject:date:message-id; bh=uQKk99NLVpf9oAITqN2Nw8x7pEHc7t+biu+B7HtwbOY=; b=WacGXgtd+fMvnhvY6lrynQfJ9qsy2nvmPPx4G3l9yaeW6i4cgmtCQS/km4w4LgHMOm Qtc7+5oatwvPwumSHi7ZbY1d6V+AfzUGjWgAzrI7b+kDFl8g4P6/nkIhejAeXsp1BrSa JJ7nVr4ijIFzpJps76Ec692dTNnI6CkIufqZz5NZRQutVwg1tRCc51Vr0+x7BUkORPfr MtKquL6y8pTD71gKS9tbBOmNER96KLsb8s6NEs/15xcLQTKcnpjJzZymlOYovtDBFw9f DW9pJ3AGTDAe7yzzUYUyfJR9kBtHdBOrvtJnoBc1w2XASzpYGJsX3jmkO4QXNHsI7z7B rV4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id; bh=uQKk99NLVpf9oAITqN2Nw8x7pEHc7t+biu+B7HtwbOY=; b=Yi4G2snckUmYDcmdph4UOfNZWHJCZ+1F6uk3LiJGGxXOoFMHrrXdy5HyxCqKrxy0yh 84SaOGDhDjBsydghfeX7pARN4fEIeRM8i9nJ5EWDJKPIv/214qlqkgGWb2L3J61AOA9b whTnvbh57bn9gOR6FKcaeJe8gjBOcr7CDMSmgCtW/4DusU/xjVww6FiQ/DK+5DpeAjif ZfbIpwYelkN7scC7czYzSaFpVsn+SSpFAWFM3FYVP6occePzfB6MSQ0DvkMEjUqAsnF5 b7mREkJK5ZynB4a9Amray9az8Aym0r1MkXuYg0nufk0p2Z30zrezijghLYeSttrohMRY zKPw== X-Gm-Message-State: AKaTC01yD3XML20fPx2oi2PWHwr219a0ApZBF013oNymVygPX5P700+MJr3T3w/Tiq1ayy8q X-Received: by 10.98.90.132 with SMTP id o126mr102633703pfb.41.1481656828741; Tue, 13 Dec 2016 11:20:28 -0800 (PST) Received: from gwendal.mtv.corp.google.com ([172.22.64.242]) by smtp.gmail.com with ESMTPSA id r74sm81662999pfl.79.2016.12.13.11.20.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Dec 2016 11:20:27 -0800 (PST) From: Gwendal Grignou To: dianders@chromium.org, hisanao.kinkawa@toshiba.co.jp, adrian.hunter@intel.com, ulf.hansson@linaro.org Cc: linux-mmc@vger.kernel.org Subject: [PATCH] mmc: core: Fix calc_max_discard. Date: Tue, 13 Dec 2016 11:20:18 -0800 Message-Id: <1481656818-21141-1-git-send-email-gwendal@chromium.org> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 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 Working with a SDHCI controller and a Toshiba 16GB THGBMFG7C2LBAIL. The Toshiba part has a large erase group size and a long erase timeout. It barely fits within the controller timeout, but mmc reports a 512B discard size to the block layer instead of the expected 4MB: /sys/block/mmcblk0/queue/discard_max_bytes = 512 The host caps[0] is 0x...b2, so host->max_busy_timeout is set to 2684.35ms: (1 << 27 / ((0xb2 & 0x3f) * 1000). In Toshiba EXT_CSD, HC_ERASE_GRP_SIZE is set to 7 (2100ms erase timeout) HC_ERASE_GRP_SIZE is set to 8, (8192 512B sectors erase size). In mmc_do_calc_max_discard(), as a safety, for eMMC device, number of erase groups that could safely be erased with the host timeout (qty) was reduced by 1. This extra safety is not necessary, given these numbers are already the worst case scenario. Moreover, in the case of this Toshiba part, given 2100 is just below 2684, qty was set to 1, we would only report one sector (512b) to the block layer, making erasing/trimming painfully slow. With this fix, using Hynix HBG4e, check that discard_max_bytes increases from 1536kB to 2048kB (qty was set to 4: each erase group size of 1024 sectors have a timeout of 600ms). Signed-off-by: Gwendal Grignou --- drivers/mmc/core/core.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 64f603e..b5a1194 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -2397,16 +2397,13 @@ static unsigned int mmc_do_calc_max_discard(struct mmc_card *card, if (!qty) return 0; - if (qty == 1) - return 1; - /* Convert qty to sectors */ if (card->erase_shift) - max_discard = --qty << card->erase_shift; + max_discard = qty << card->erase_shift; else if (mmc_card_sd(card)) max_discard = qty; else - max_discard = --qty * card->erase_size; + max_discard = qty * card->erase_size; return max_discard; }