From patchwork Fri Mar 1 07:57:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shawn Lin X-Patchwork-Id: 10834581 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4010F1399 for ; Fri, 1 Mar 2019 07:58:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 30B4B2ECE7 for ; Fri, 1 Mar 2019 07:58:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 216612F3DA; Fri, 1 Mar 2019 07:58:38 +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.4 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_WEB 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 CFC632ECE7 for ; Fri, 1 Mar 2019 07:58:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727344AbfCAH6f (ORCPT ); Fri, 1 Mar 2019 02:58:35 -0500 Received: from lucky1.263xmail.com ([211.157.147.135]:40906 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728235AbfCAH6e (ORCPT ); Fri, 1 Mar 2019 02:58:34 -0500 Received: from shawn.lin?rock-chips.com (unknown [192.168.167.239]) by lucky1.263xmail.com (Postfix) with ESMTP id 3A20A3260; Fri, 1 Mar 2019 15:58:23 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 Received: from localhost.localdomain (unknown [58.22.7.114]) by smtp.263.net (postfix) whith ESMTP id P13901T140115290605312S1551427101430305_; Fri, 01 Mar 2019 15:58:22 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: X-RL-SENDER: shawn.lin@rock-chips.com X-SENDER: lintao@rock-chips.com X-LOGIN-NAME: shawn.lin@rock-chips.com X-FST-TO: ulf.hansson@linaro.org X-SENDER-IP: 58.22.7.114 X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 From: Shawn Lin To: Ulf Hansson Cc: Jaehoon Chung , Minda Chen , linux-mmc@vger.kernel.org, Adrian Hunter , Douglas Anderson , Shawn Lin Subject: [RFC PATCH] mmc: core: Add MMC_CAP2_NO_TUNING_CMP support Date: Fri, 1 Mar 2019 15:57:08 +0800 Message-Id: <1551427028-103750-1-git-send-email-shawn.lin@rock-chips.com> X-Mailer: git-send-email 1.9.1 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 This caps2 is to skip doing memory compare tuning block pattern with the received data from devices when doing tuning. The data from device is all formatted like: Start bit + data + CRC + End bit For normal data read, we just verify host sample the data w/o any errors, but not need care the data context. But for a tuning process, we now compare the data context with JEDEC pattern. I highly suspect the rational behide it for the following details: (1) The tuning process is mostly used for identifing the rational sample window, so if the host read the tuning block successfully like a noraml data read, isn't it enough for sure that *this* single sample phase is good to work, no? The original patch to support it didn't quote any spec details but let's see the JESD84-B51, section 6.6.5, "Bus Sampling Tuning Concept" just says "This example is given for concept explanation purpose. The Host may use any other implementation according to its design consideration. " The concept isn't the order, and whether the MMC core need to verify the tuning block? See my argue (2). (2) AFAICT, the tuning block is handled by a fixed HW module within the device, if a JEDEC compatible device receive tuning block cmd and response it, could it sends back a non-compatible tuning block? (3) Some(it's impossible for me to check all) of the SDHCI IP instances at hand which do tuning by HW block,never check the tuning block at all. I'm intended to remove it entirely but just stay back a bit for skipping that if any vendors are willing to try(At least rockchip does). Any comments will be appreciated. Signed-off-by: Shawn Lin --- drivers/mmc/core/mmc_ops.c | 3 ++- include/linux/mmc/host.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index c5208fb..802cba5 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -664,7 +664,8 @@ int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error) goto out; } - if (memcmp(data_buf, tuning_block_pattern, size)) + if (!(host->caps & MMC_CAP2_NO_TUNING_CMP) && + memcmp(data_buf, tuning_block_pattern, size)) err = -EIO; out: diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h index 43d0f0c..8e759ff 100644 --- a/include/linux/mmc/host.h +++ b/include/linux/mmc/host.h @@ -370,6 +370,7 @@ struct mmc_host { #define MMC_CAP2_CQE (1 << 23) /* Has eMMC command queue engine */ #define MMC_CAP2_CQE_DCMD (1 << 24) /* CQE can issue a direct command */ #define MMC_CAP2_AVOID_3_3V (1 << 25) /* Host must negotiate down from 3.3V */ +#define MMC_CAP2_NO_TUNING_CMP (1 << 25) /* Do not need compare the tuning block */ int fixed_drv_type; /* fixed driver type for non-removable media */