All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vitalywool@gmail.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: drzeus-mmc@drzeus.cx, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix random SD/MMC card recognition failures on ARM Versatile
Date: Fri, 24 Nov 2006 10:54:23 +0300	[thread overview]
Message-ID: <20061124105423.e799e73e.vitalywool@gmail.com> (raw)
In-Reply-To: <20061123194236.GD8984@flint.arm.linux.org.uk>

On Thu, 23 Nov 2006 19:42:36 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Ah, I see it.  In that case we need to call mmc_stop_data() when
> we're ending the initial command due to an error.  IOW, like this:
<snip> 

I'd suggest arranging that in a bit different way. It looks like it works better when MMCIDATACTRL/MMCIMASK1 are cleared after MMCICOMMAND (and I think it makes more sense to clear the command register first, thus we have less change to get spurious interrupts after MMCIMASK1 is set).

diff --git a/drivers/mmc/mmci.c b/drivers/mmc/mmci.c
index 828503c..afbb63b 100644
--- a/drivers/mmc/mmci.c
+++ b/drivers/mmc/mmci.c
@@ -37,11 +37,21 @@ #define DBG(host,fmt,args...)	\
 
 static unsigned int fmax = 515633;
 
+static void mmci_stop_data(struct mmci_host *host)
+{
+	writel(0, host->base + MMCIDATACTRL);
+	writel(0, host->base + MMCIMASK1);
+	host->data = NULL;
+}
+
 static void
 mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
 {
 	writel(0, host->base + MMCICOMMAND);
 
+	if (host->data)
+		mmci_stop_data(host);
+
 	host->mrq = NULL;
 	host->cmd = NULL;
 
@@ -57,13 +67,6 @@ mmci_request_end(struct mmci_host *host,
 	spin_lock(&host->lock);
 }
 
-static void mmci_stop_data(struct mmci_host *host)
-{
-	writel(0, host->base + MMCIDATACTRL);
-	writel(0, host->base + MMCIMASK1);
-	host->data = NULL;
-}
-
 static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 {
 	unsigned int datactrl, timeout, irqmask;
@@ -168,8 +171,6 @@ mmci_data_irq(struct mmci_host *host, st
 			flush_dcache_page(host->sg_ptr->page);
 	}
 	if (status & MCI_DATAEND) {
-		mmci_stop_data(host);
-
 		if (!data->stop) {
 			mmci_request_end(host, data->mrq);
 		} else {


Vitaly

      parent reply	other threads:[~2006-11-24  7:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-23 15:46 [PATCH] fix random SD/MMC card recognition failures on ARM Versatile Vitaly Wool
2006-11-23 16:03 ` Russell King
2006-11-23 19:29   ` Vitaly Wool
2006-11-23 19:42     ` Russell King
2006-11-23 19:57       ` Russell King
2006-11-24  7:54       ` Vitaly Wool [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061124105423.e799e73e.vitalywool@gmail.com \
    --to=vitalywool@gmail.com \
    --cc=drzeus-mmc@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.