From patchwork Tue Jan 8 17:23:12 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?=C5=81ukasz_Majewski?= X-Patchwork-Id: 210445 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 069E12C008F for ; Wed, 9 Jan 2013 04:23:42 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 741FA4A103; Tue, 8 Jan 2013 18:23:39 +0100 (CET) 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 AvJlWn0QBHA6; Tue, 8 Jan 2013 18:23:39 +0100 (CET) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 8408E4A105; Tue, 8 Jan 2013 18:23:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id D68E64A105 for ; Tue, 8 Jan 2013 18:23:29 +0100 (CET) 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 hy2rcqcIakY4 for ; Tue, 8 Jan 2013 18:23:27 +0100 (CET) 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 mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by theia.denx.de (Postfix) with ESMTP id 2DA8D4A103 for ; Tue, 8 Jan 2013 18:23:25 +0100 (CET) Received: from epcpsbgm1.samsung.com (epcpsbgm1 [203.254.230.26]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MGB00FNOHMQBL10@mailout4.samsung.com> for u-boot@lists.denx.de; Wed, 09 Jan 2013 02:23:23 +0900 (KST) X-AuditID: cbfee61a-b7fa66d0000004cf-de-50ec560a1e17 Received: from epmmp1.local.host ( [203.254.227.16]) by epcpsbgm1.samsung.com (EPCPMTA) with SMTP id 55.96.01231.A065CE05; Wed, 09 Jan 2013 02:23:22 +0900 (KST) Received: from mcdsrvbld02.digital.local ([106.116.37.23]) by mmp1.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MGB007K8HMRZQ10@mmp1.samsung.com> for u-boot@lists.denx.de; Wed, 09 Jan 2013 02:23:22 +0900 (KST) From: Lukasz Majewski To: u-boot@lists.denx.de Date: Tue, 08 Jan 2013 18:23:12 +0100 Message-id: <1357665792-8141-1-git-send-email-l.majewski@samsung.com> X-Mailer: git-send-email 1.7.10 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNJMWRmVeSWpSXmKPExsVy+t9jAV2usDcBBvvarC3e7u1kd2D0OHtn B2MAYxSXTUpqTmZZapG+XQJXRv+5BvaCL/wVLW2/2RoYv/F0MXJySAiYSKw7+osdwhaTuHBv PVsXIxeHkMAiRoldU28yQziLmST+fXnPClLFJqAn8fnuUyYQW0RAQuJX/1VGkCJmkKJHXZsZ QRLCAt4S63a8BbNZBFQlWhY8BZrEwcEr4Cpx7kQkxDZ5iaf3+9gmMHIvYGRYxSiaWpBcUJyU nmuoV5yYW1yal66XnJ+7iRHsxWdSOxhXNlgcYhTgYFTi4b0U8zpAiDWxrLgy9xCjBAezkgjv Xe83AUK8KYmVValF+fFFpTmpxYcYpTlYlMR5GU89CRASSE8sSc1OTS1ILYLJMnFwSjUwBp96 JMqla6mjcG9KeYHYoyP5i5dzGNoePzJfqXb1wsipp06sErj5ouZU+c1pPlb/MhzFUyLsus9J 3T6tqLjpLzd73CEbs+XhOeIrXYvDLohrN3C/U1mWsmPLd89b4QUfpnyNFt7P9rrlsDrP1EV6 +/g0b1mZ+N+5kLvKxDlM5OXyKx7XmQ/OUmIpzkg01GIuKk4EAFYUH3PeAQAA Cc: Jaehoon Chung , Kyungmin Park , afleming@freescale.com, Tom Rini , Andy Fleming , Lukasz Majewski Subject: [U-Boot] [RFC] mmc:fix: Increase the timeout value for SDHCI_send_command() 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 I'd like to ask for your opinion about the following problem: TRATS # saveenv Saving Environment to MMC... Writing to MMC(0)... Controller never released inhibit bit(s). Controller never released inhibit bit(s). Controller never released inhibit bit(s). ... failed The same is for e.g. ext4. The provided patch seems to solve the problem, but I DO NOT think that increasing delay is an acceptable solution to any problem. From a brief checking I can say that it happens when we are doing consecutive MMC operations (i.e. many reads), and the 10ms timeout might be too short when eMMC firmware is forced to do some internal time consuming operations (e.g. flash blocks management, wear leveling). In this situation, the SDHCI_CMD_INHIBIT bit is set, which means that SDHCI controller didn't received response from eMMC. One proposition would be to define the per device/per memory chip specific timeouts, to replace those defined at ./drivers/mmc/sdhci.c file. I also assume, that timeouts cannot be removed, since we must detect if user pulls out a SD card or transmission has been broken. I'm also wondering if we can tune the sdhci code to improve cooperation with eMMC devices (despite of the fact that this is NOT really needed at u-boot :-) ). Signed-off-by: Lukasz Majewski Cc: Jaehoon Chung Cc: Andy Fleming --- drivers/mmc/sdhci.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index b9cbe34..0fd1337 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -137,8 +137,8 @@ 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; + /* Wait max 100 ms */ + timeout = 100; sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS); mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT;