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;