From patchwork Mon Dec 8 10:10:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 5455361 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 17B2E9F30B for ; Mon, 8 Dec 2014 10:10:11 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2E24620172 for ; Mon, 8 Dec 2014 10:10:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3D01020142 for ; Mon, 8 Dec 2014 10:10:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753514AbaLHKKH (ORCPT ); Mon, 8 Dec 2014 05:10:07 -0500 Received: from mail-qc0-f171.google.com ([209.85.216.171]:42418 "EHLO mail-qc0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752717AbaLHKKG (ORCPT ); Mon, 8 Dec 2014 05:10:06 -0500 Received: by mail-qc0-f171.google.com with SMTP id r5so3242853qcx.2 for ; Mon, 08 Dec 2014 02:10:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OorpnXq+A9Vjff84O3gfIpHMBZl7R8F5jguQm5NMXMQ=; b=emGkT7bGKkzlpVWKnX37aiakArEC2Bhu5GW7LpQV65UgfjGDH9qAdxvecajILroc1w X/cQYoUwsvHv6SvLHXrRtwKagGwBW5L2mnHjViW39hTK06O4t4AQ3L14ApHrdzWYYpQm aE/OrS7Qv6f/ghmLbZ5fVf6fQHr6dwxi7GS+EFUDWCD4J84uiuhJ0/yhRjbcRWFOgCyw QQpWt41mAPOqsOkucaPQf1m5y1tfi95IJedvKI3w4b63GspxLcKHFVwX5U9ga6qrkTB8 1dnjrAaFV68VDZEjW7xLjUXkCRPeC0UhHFAeqLqtzHIurU43c+3N8vpys5c1VYrOYdRx M9rw== X-Gm-Message-State: ALoCoQlAI0IUp3hwQCRzg2PjQSe29SIkfLXntAjEr7YvFNiqyEMUlGL2xMDb/IrndU+Z/oY0saBm MIME-Version: 1.0 X-Received: by 10.140.85.104 with SMTP id m95mr48286713qgd.93.1418033405431; Mon, 08 Dec 2014 02:10:05 -0800 (PST) Received: by 10.96.216.199 with HTTP; Mon, 8 Dec 2014 02:10:05 -0800 (PST) In-Reply-To: References: <1417780783-12939-1-git-send-email-ulf.hansson@linaro.org> <1417780783-12939-4-git-send-email-ulf.hansson@linaro.org> Date: Mon, 8 Dec 2014 11:10:05 +0100 Message-ID: Subject: Re: [PATCH v2 3/4] mmc: dw_mmc: Convert to mmc_send_tuning() From: Ulf Hansson To: Alim Akhtar Cc: "linux-mmc@vger.kernel.org" , Chris Ball , Seungwon Jeon , Jaehoon Chung , Shawn Guo , Sascha Hauer , Aisheng Dong , Stephen Boyd , Minda Chen , Barry Song Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 6 December 2014 at 13:43, Alim Akhtar wrote: > Hi Ulf, > > On Fri, Dec 5, 2014 at 5:29 PM, Ulf Hansson wrote: >> Instead of having a local hack taking care of sending the tuning >> command and as well to verify the response pattern, let's convert to >> the common mmc_send_tuning() API. >> >> This change affects the Exynos variant, since it's the only one which >> support the dw_mmc's ->execute_tuning() callback. >> >> Signed-off-by: Ulf Hansson >> --- >> Alim, thanks for helping out testing! > With this change HS200 mode does not work on exynos5800 peach-pi board. > I got below error while testing this series: > > mmc0: tuning execution failed > mmc0: error -5 whilst initialising MMC card > > Though, your's next branch with commit _a1d06b4_ works fine in HS200 mode. I was looking into the details of what change my patchset introduces for dw_mmc-exynos. Apparently, dw_mmc-exynos was using the MMC_STOP_TRANSMISSION to end the tuning reqeust (CMD21/19). The new mmc_send_tuning() API doesn't, which also conforms to what the eMMC/SD specifications states. Do you have any idea of why dw_mmc-exynos was using MMC_STOP_TRANSMISSION for CMD19/21? To see if my theory is correct, could you try out the following patch on top of $subject patch? BTW, I have queued patch 1 and 2, from this patchset available on my next branch. From e1ac35bb0e90254275ec7088f41e6e2d59e48367 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Mon, 8 Dec 2014 10:58:48 +0100 Subject: [PATCH] mmc: core: End tuning request with stop command Not to be merged! This patch adds the MMC_STOP_TRANSMISSION command to end a tuning request. For some reason dw_mmc seems to need this to complete the tuning request without errors. Signed-off-by: Ulf Hansson --- drivers/mmc/core/mmc_ops.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index 3b044c5..aa79e0c 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -551,6 +551,7 @@ int mmc_send_tuning(struct mmc_host *host) { struct mmc_request mrq = {NULL}; struct mmc_command cmd = {0}; + struct mmc_command stop = {0}; struct mmc_data data = {0}; struct scatterlist sg; struct mmc_ios *ios = &host->ios; @@ -576,10 +577,14 @@ int mmc_send_tuning(struct mmc_host *host) mrq.cmd = &cmd; mrq.data = &data; + mrq.stop = &stop; cmd.opcode = opcode; cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC; + stop.opcode = MMC_STOP_TRANSMISSION; + stop.flags = MMC_RSP_R1B | MMC_CMD_AC; + data.blksz = size; data.blocks = 1; data.flags = MMC_DATA_READ;