From patchwork Mon Feb 16 16:07:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrzej Hajda X-Patchwork-Id: 5833901 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id CA8D3BF440 for ; Mon, 16 Feb 2015 16:08:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0B2F5201B9 for ; Mon, 16 Feb 2015 16:08:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 84A3D2017E for ; Mon, 16 Feb 2015 16:08:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753288AbbBPQIj (ORCPT ); Mon, 16 Feb 2015 11:08:39 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:63928 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753081AbbBPQIi (ORCPT ); Mon, 16 Feb 2015 11:08:38 -0500 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NJV00FL3H14RM80@mailout3.w1.samsung.com> for linux-mmc@vger.kernel.org; Mon, 16 Feb 2015 16:12:40 +0000 (GMT) X-AuditID: cbfec7f4-b7f126d000001e9a-a8-54e215731b1b Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 2B.D8.07834.37512E45; Mon, 16 Feb 2015 16:06:11 +0000 (GMT) Received: from AMDC1061.digital.local ([106.116.147.88]) by eusync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0NJV000QXGTXVA10@eusync4.samsung.com>; Mon, 16 Feb 2015 16:08:36 +0000 (GMT) From: Andrzej Hajda To: linux-mmc@vger.kernel.org Cc: Andrzej Hajda , Seungwon Jeon , Jaehoon Chung , Chris Ball , Ulf Hansson , Marek Szyprowski , Kyungmin Park , addy.ke@rock-chips.com, alim.akhtar@gmail.com, javier@dowhile0.org Subject: [RFC PATCH] mmc: dw_mmc: mark card as removed if error occurs and status is busy Date: Mon, 16 Feb 2015 17:07:41 +0100 Message-id: <1424102861-30064-1-git-send-email-a.hajda@samsung.com> X-Mailer: git-send-email 1.9.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsVy+t/xa7rFoo9CDJ695re4te4cq8Wy/9+Z LJbeqraYcHk7o8W13zPYLG78amO1ONv0ht3iyP9+Rou1R+6yW3y4f5HZ4vjacAduj7+zW5k9 ds66y+5x59oeNo8brxYyefydtZ/Fo2/LKkaPz5vkAtijuGxSUnMyy1KL9O0SuDK+HdjAVHBV uOLxs12MDYzdAl2MnBwSAiYSDYcusUHYYhIX7q0Hsrk4hASWMkrMvv+BFcLpY5KYs6yHHaSK TUBT4u/mm2AdIgKyEj//XADrYBZ4wCTR/u4CM0hCWCBa4vTTWUwgNouAqsTDbwvA4rwCzhKz /vxkglgnJ3Hy2GTWCYzcCxgZVjGKppYmFxQnpeca6hUn5haX5qXrJefnbmKEBNiXHYyLj1kd YhTgYFTi4d0Q9iBEiDWxrLgy9xCjBAezkgjvsvcPQ4R4UxIrq1KL8uOLSnNSiw8xMnFwSjUw zr2d+3hZ1NQvrQb9LsevRoQE1+4+l9C2NPPnow9GJjLMXim5+y10/674V7Zy+ue/JYofN7rI tB4+Z/LAgZcleXtS2dKaRtk9FzK/LZTWEXyuLrL6qNNDJf3iMl0rBWn/8nUvbhkkmu5avHrR 2X2PCw81Bv/tPH/3kFhIze68q2y373TWaR8NVmIpzkg01GIuKk4EAN82ZhAOAgAA 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=unavailable 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 some boards with broken card detection if eMMC card is not present system hangs during mmc_rescan. The sequence is as below: mmc_rescan_try_freq:sdio_reset: > send CMD52 < irq with SDMMC_INT_RESP_ERR and SDMMC_STATUS_BUSY < irq with SDMMC_INT_CMD_DONE and SDMMC_STATUS_BUSY > dw_mci_wait_busy:dw_mci_ctrl_reset < irq with SDMMC_INT_RESP_ERR | SDMMC_INT_CMD_DONE and status not busy > send CMD52 ... mmc_rescan waits infinitely for irq in mmc_wait_for_req It seems hardware enters into some strange state after issuing CMD52 to non-existing card. It stops signaling IRQs and it can even hang on accessing some registers, for example UHS_REG or CTYPE. The patch tries to solve it by resetting the controller and marking card as removed, as a result no further commands will be issued until next rescan. The issue has been observed on Odroid-XU3 boards (Exynos5422 with dw_mmc 250A). Signed-off-by: Andrzej Hajda --- Hi, I am not familiar with MMC internals so please verify patch (in-)sanity. Especially I am not sure if (SDMMC_INT_RESP_ERR | SDMMC_INT_CMD_DONE with status busy) occurs only in this situation, if no, more precise check should be added, I guess. Or maybe it should be a quirk??? The patch is based on Addy's 'about data busy' patchset [1]. Alim's advice about stabilization of host voltage has been tested also, without success [2]. [1]: http://permalink.gmane.org/gmane.linux.kernel/1888161 [2]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31202 Regards Andrzej --- drivers/mmc/host/dw_mmc.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 692d97a..3cba1eb 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -2182,8 +2182,19 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id) } if (pending & SDMMC_INT_CMD_DONE) { + u32 err = (pending | host->cmd_status) & + SDMMC_INT_RESP_ERR; + struct dw_mci_slot *slot = host->cur_slot; + mci_writel(host, RINTSTS, SDMMC_INT_CMD_DONE); - dw_mci_cmd_interrupt(host, pending); + if (err && dw_mci_card_busy(slot->mmc)) { + u32 ctrl = mci_readl(host, CTRL); + + ctrl |= SDMMC_CTRL_ALL_RESET_FLAGS; + mci_writel(host, CTRL, ctrl); + clear_bit(DW_MMC_CARD_PRESENT, &slot->flags); + } else + dw_mci_cmd_interrupt(host, pending); } if (pending & SDMMC_INT_CD) {