From patchwork Tue Sep 3 12:50:31 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Przemyslaw Marczak X-Patchwork-Id: 272230 X-Patchwork-Delegate: promsoft@gmail.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 617512C00A4 for ; Tue, 3 Sep 2013 22:51:24 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id CAE734A068; Tue, 3 Sep 2013 14:51:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NqqnJA-xbyd; Tue, 3 Sep 2013 14:51:22 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id C30D34A06E; Tue, 3 Sep 2013 14:51:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 4CF764A06E for ; Tue, 3 Sep 2013 14:51:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYGFTKu4Ridt for ; Tue, 3 Sep 2013 14:51:10 +0200 (CEST) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by theia.denx.de (Postfix) with ESMTP id 0670F4A068 for ; Tue, 3 Sep 2013 14:51:04 +0200 (CEST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MSJ004H4VOQTU40@mailout1.w1.samsung.com> for u-boot@lists.denx.de; Tue, 03 Sep 2013 13:50:59 +0100 (BST) X-AuditID: cbfec7f5-b7ef66d00000795a-c7-5225db332246 Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 28.CC.31066.33BD5225; Tue, 03 Sep 2013 13:50:59 +0100 (BST) Received: from AMDC1186.digital.local ([106.116.147.185]) by eusync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0MSJ00CMEVOWEF40@eusync1.samsung.com>; Tue, 03 Sep 2013 13:50:59 +0100 (BST) From: Przemyslaw Marczak To: u-boot@lists.denx.de Date: Tue, 03 Sep 2013 14:50:31 +0200 Message-id: <1378212631-25526-1-git-send-email-p.marczak@samsung.com> X-Mailer: git-send-email 1.7.9.5 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMJMWRmVeSWpSXmKPExsVy+t/xy7rGt1WDDGa1SVrc+NXGarHj8g0W i123J7NYvN3bye7A4jHv50Qmj7N3djB69G1ZxRjAHMVlk5Kak1mWWqRvl8CV8fzvBeaCebwV 7UsPsTQwXuTqYuTkkBAwkfhy9yozhC0mceHeejYQW0hgKaPEmwaLLkYuILuPSeL87OssIAk2 AQOJPZfOgDWICEhI/Oq/yghiMwukS/ye1soOYgsLWEk09G5kBbFZBFQltuyZAFTPwcEr4Crx fJ4yiCkhoCAxZ5LNBEbuBYwMqxhFU0uTC4qT0nON9IoTc4tL89L1kvNzNzFCPP51B+PSY1aH GAU4GJV4eBP2qwQJsSaWFVfmHmKU4GBWEuHlP6UaJMSbklhZlVqUH19UmpNafIiRiYNTqoHx csnFtv8HMy8bnlzgdKAjp2jb6bfnLPQzuDgtJtfdVhFTdj2nEiVf9Eb6SKdt3SNJ3RnlQvPO 2sdP3rw3J6mD3+nUPJ7w9ywqJZn59du1hJglPP6cOlTuIOLvw2G/T+PBq/vttXsmrK1NyCuY 353fsCNsZWSjwiWOrBWdbjfPhrQfF315116JpTgj0VCLuag4EQDfmiu31gEAAA== Cc: jh80.chung@samsung.com, panto@antoniou-consulting.com, Przemyslaw Marczak Subject: [U-Boot] [PATCH] mmc:sdhci: Fix card ready status timeout. X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de According to JEDEC eMMC specification, after data transfer (multiple or single block) host must wait for card ready status. This is done by waiting for command and data lines to be at idle state after transfer. JEDEC does not specify maximum timeout. Before this change max timeout was 10 ms but in case of UMS - when system does multiple read/write operations on random card blocks - timeout causes I/O errors. The timeout has been increased to 200ms after data transfer. For other transfers it stays unchanged. Tested on Goni and Trats. Signed-off-by: Przemyslaw Marczak Cc: Pantelis Antoniou --- drivers/mmc/sdhci.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 4261991..c495482 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -121,8 +121,18 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, unsigned int timeout, start_addr = 0; unsigned int retry = 10000; - /* Wait max 10 ms */ - timeout = 10; + /* + * For some commands this function is called with NULL mmc_data + * pointer. One of those is CMD13 - send card status. + * After read/write data transfer or block erase commands - host sends + * CMD13 and is waiting for card ready status with some timeout. + * According to some internal cards operations after those commands + * this time must be increased. + */ + if (data) + timeout = 10; /* ms */ + else + timeout = 200; sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS); mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;