From patchwork Mon Jul 3 19:28:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Wolfram Sang X-Patchwork-Id: 9823857 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 C13F6604D9 for ; Mon, 3 Jul 2017 19:28:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B193722B1F for ; Mon, 3 Jul 2017 19:28:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A5CDF27FB1; Mon, 3 Jul 2017 19:28:39 +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.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable 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 0F98D27F82 for ; Mon, 3 Jul 2017 19:28:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753834AbdGCT2f (ORCPT ); Mon, 3 Jul 2017 15:28:35 -0400 Received: from sauhun.de ([88.99.104.3]:45925 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753369AbdGCT2f (ORCPT ); Mon, 3 Jul 2017 15:28:35 -0400 Received: from localhost (p54B33856.dip0.t-ipconnect.de [84.179.56.86]) by pokefinder.org (Postfix) with ESMTPSA id C84632C358D; Mon, 3 Jul 2017 21:28:31 +0200 (CEST) From: Wolfram Sang To: linux-mmc@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org, =?UTF-8?q?Jan=20Kl=C3=B6tzke?= , Geert Uytterhoeven , Simon Horman , Yoshihiro Shimoda , Masaharu Hayakawa , Kouei Abe , Wolfram Sang Subject: [RFT] mmc: tmio: fix CMD12 (STOP) handling Date: Mon, 3 Jul 2017 21:28:23 +0200 Message-Id: <20170703192823.8116-1-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.11.0 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 I always anticipated this code to be not correct, but now I had a test case to prove it. According to all documentation I have, setting the TMIO_STOP_STP bit ever only worked during block transfers. This bit is like manually enforcing an autocmd12 during a so far seamless transfer. It does NOT work when the block transfer had errors. It also does NOT work with any other cmd except block commands. For all those, CMD12 has to be treated like any other command. So, basically, we could use this bit only for mrq->data->stop cmds. But for these, we happily use the autocmd12 feature using the TMIO_STOP_SEC bit. As a result, the above bit is not useful for us and we need to treat CMD12 as a regular cmd always. Just remove the special handling code. Note that the BSP recognized this issue as well yet had a more cautious solution to the problem [1]. Which is understandable but makes CMD12 handling even more complicated. Checked with a Renesas Salvator-X/M3-W which needed to send CMD12 when retuning one of my SD cards. [1] https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=2838a2ff8ca776f6d18b7fbbe75f3df8dd64183a Signed-off-by: Wolfram Sang Tested-by: Jan Klötzke Tested-by: Nguyen Viet Dung --- So, this is a friendly call for further testing to make sure no regressions happen. I also put the authors of the BSP patch to CC to check if this patch also matches their use case. I hope this is fine for these people, please accept my apologies if not. I just really like to have your opinion on this patch. Geert, Simon: any chance you can run this patch on your board farms? In any case: as far as my understanding goes, if I am wrong with my assumptions, the worst case is that for older SoCs CMD12 handling might become a tad more inefficient because we now do in software what was expected to be done in hardware. However, I am quite sure that the HW feature was always over-estimated and CMD12 support is simply broken. For my test case and the BSP patch above, it definately was. Thanks for any assistance, Wolfram drivers/mmc/host/tmio_mmc_core.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c index 1851c883bfc82a..fbcd56c58bce24 100644 --- a/drivers/mmc/host/tmio_mmc_core.c +++ b/drivers/mmc/host/tmio_mmc_core.c @@ -355,12 +355,6 @@ static int tmio_mmc_start_command(struct tmio_mmc_host *host, int c = cmd->opcode; u32 irq_mask = TMIO_MASK_CMD; - /* CMD12 is handled by hardware */ - if (cmd->opcode == MMC_STOP_TRANSMISSION && !cmd->arg) { - sd_ctrl_write16(host, CTL_STOP_INTERNAL_ACTION, TMIO_STOP_STP); - return 0; - } - switch (mmc_resp_type(cmd)) { case MMC_RSP_NONE: c |= RESP_NONE; break; case MMC_RSP_R1: