Re: [PATCH] OMAP: MMC: replace infinite loops with timeouts (was Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend)
wrote:
An infinite loop which assumes the hardware is perfect is always a
worry. But I see the driver already does that, so we're no worse
off..
Do you want a finite loop with udelay in it? I located 4 places were
this could be used. If so I can generate a new patch for that.
Even if Andrew doesn't, I'd sure like it. (the finite bit at least) :)
Ok here is a patch that replaces the infinite loops with a timeout
version. This patch applies on top of the previous one I sent ('[PATCH]
OMAP: MMC: recover from transfer failures - Resend'). Is that OK?
What about making use of a function like this:
static void reset_host_controller(struct mmc_omap_host *host, unsigned bit)
{
unsigned long i, limit = loops_per_jiffy;
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
for (i = 0; i limit; i++) {
if (!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
return;
cpu_relax();
}
dev_err(mmc_dev(host-mmc), %s: timeout waiting on software reset\n,
mmc_hostname(host-mmc));
}
And then just put:
reset_host_controller(host, SRD);
and
reset_host_controller(host, SRC);
in the right places.
From 9d1993dcf4d217837437a1cd9f6e9c1b81533549 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Fri, 6 Feb 2009 16:42:51 +0100
Subject: [PATCH] OMAP: MMC: Change while(); loops with finite version
Replace the infinite 'while() ;' loops
with a finite loop version.
Signed-off-by: Jean Pihet jpi...@mvista.com
---
drivers/mmc/host/omap_hsmmc.c | 54 ++--
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1ac6918..aabf28d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -375,6 +375,32 @@ static void mmc_omap_report_irq(struct mmc_omap_host *host, u32 status)
}
#endif /* CONFIG_MMC_DEBUG */
+/*
+ * MMC controller internal state machines reset
+ *
+ * Used to reset command or data internal state machines, using respectively
+ * SRC or SRD bit of SYSCTL register
+ * Can be called from interrupt context
+ */
+static inline void mmc_omap_reset_controller_fsm(struct mmc_omap_host *host,
+ unsigned long bit)
+{
+ unsigned long i = 0;
+ unsigned long limit = (loops_per_jiffy *
+msecs_to_jiffies(MMC_TIMEOUT_MS));
+
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
+
+ while ((OMAP_HSMMC_READ(host-base, SYSCTL) bit)
+ (i++ limit))
+ cpu_relax();
+
+ if (OMAP_HSMMC_READ(host-base, SYSCTL) bit)
+ dev_err(mmc_dev(host-mmc),
+ Timeout waiting on controller reset in %s\n,
+ __func__);
+}
/*
* MMC controller IRQ handler
@@ -403,13 +429,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
(status CMD_CRC)) {
if (host-cmd) {
if (status CMD_TIMEOUT) {
- OMAP_HSMMC_WRITE(host-base, SYSCTL,
- OMAP_HSMMC_READ(host-base,
-SYSCTL) | SRC);
- while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRC)
- ;
-
+ mmc_omap_reset_controller_fsm(host, SRC);
host-cmd-error = -ETIMEDOUT;
} else {
host-cmd-error = -EILSEQ;
@@ -418,12 +438,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
if (host-data) {
mmc_dma_cleanup(host);
-OMAP_HSMMC_WRITE(host-base, SYSCTL,
- OMAP_HSMMC_READ(host-base,
- SYSCTL) | SRD);
-while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRD)
- ;
+mmc_omap_reset_controller_fsm(host, SRD);
}
}
if ((status DATA_TIMEOUT) ||
@@ -433,12 +448,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
mmc_dma_cleanup(host);
else
host-data-error = -EILSEQ;
-OMAP_HSMMC_WRITE(host-base, SYSCTL,
- OMAP_HSMMC_READ(host-base,
- SYSCTL) | SRD);
-while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRD)
- ;
+mmc_omap_reset_controller_fsm(host, SRD);
end_trans = 1;
}
}
@@ -529,11 +539,7 @@ static void mmc_omap_detect(struct work_struct *work)
if (host-carddetect) {
mmc_detect_change(host-mmc, (HZ * 200) / 1000);
} else {
- OMAP_HSMMC_WRITE(host-base, SYSCTL,
- OMAP_HSMMC_READ(host-base, SYSCTL) | SRD);
- while (OMAP_HSMMC_READ(host-base, SYSCTL) SRD)
- ;
-
+ mmc_omap_reset_controller_fsm(host, SRD);
mmc_detect_change(host-mmc, (HZ * 50) / 1000);
}
}
--
1.6.0.1.42.gf8c9c
Re: [PATCH] OMAP: MMC: replace infinite loops with timeouts (was Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend)
Jean Pihet wrote:
Hi,
On Thu, 5 Feb 2009, Andrew Morton wrote:
An infinite loop which assumes the hardware is perfect is always a
worry. But I see the driver already does that, so we're no worse
off..
Do you want a finite loop with udelay in it? I located 4 places were this
could be used. If so I can generate a new patch for that.
Even if Andrew doesn't, I'd sure like it. (the finite bit at least) :)
Ok here is a patch that replaces the infinite loops with a timeout version.
This patch applies on top of the previous one I sent ('[PATCH] OMAP: MMC:
recover from transfer failures - Resend'). Is that OK?
What about making use of a function like this:
static void reset_host_controller(struct mmc_omap_host *host, unsigned bit)
{
unsigned long i, limit = loops_per_jiffy;
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
for (i = 0; i limit; i++) {
if (!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
return;
cpu_relax();
}
dev_err(mmc_dev(host-mmc), %s: timeout waiting on software reset\n,
mmc_hostname(host-mmc));
}
And then just put:
reset_host_controller(host, SRD);
and
reset_host_controller(host, SRC);
in the right places.
Related, who is the maintainer of this driver? Tony? I'd like to have
someone who checks patches before I queue them up.
Rgds
From 5ee867d09efe22a903ac7373a05e9e047bad6544 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Fri, 6 Feb 2009 16:42:51 +0100
Subject: [PATCH] OMAP: MMC: replace infinite loops with timeouts
Replace the 'while() ;' with a timeout
Signed-off-by: Jean Pihet jpi...@mvista.com
---
drivers/mmc/host/omap_hsmmc.c | 56
+
1 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1ac6918..7ddc77e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -102,6 +102,8 @@
#define OMAP_MMC_DATADIR_READ 1
#define OMAP_MMC_DATADIR_WRITE 2
#define MMC_TIMEOUT_MS 20
+#define MMC_TIMEOUT_WAIT 100 /* Active wait duration, in usec */
+#define MMC_TIMEOUT_WAIT_LOOPS ((MMC_TIMEOUT_MS * 1000) / MMC_TIMEOUT_WAIT)
#define OMAP_MMC_MASTER_CLOCK 9600
#define DRIVER_NAMEmmci-omap-hs
@@ -384,6 +386,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
struct mmc_omap_host *host = dev_id;
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+ unsigned long timeout_counter;
if (host-cmd == NULL host-data == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
@@ -406,9 +409,17 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base,
SYSCTL) |
SRC);
- while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRC)
- ;
+ timeout_counter = 0;
+ while ((OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRC)
+(timeout_counter++
+
MMC_TIMEOUT_WAIT_LOOPS))
+
udelay(MMC_TIMEOUT_WAIT);
+
+ if (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRC)
+ dev_err(mmc_dev(host-mmc),
+ Timeout waiting on
SRC\n);
host-cmd-error = -ETIMEDOUT;
} else {
@@ -421,9 +432,17 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base,
SYSCTL) | SRD);
- while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRD)
- ;
+ timeout_counter = 0;
+ while ((OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+(timeout_counter++
+
MMC_TIMEOUT_WAIT_LOOPS))
+ udelay(MMC_TIMEOUT_WAIT);
+
+ if (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
Pierre Ossman wrote: Related, who is the maintainer of this driver? Tony? I'd like to have someone who checks patches before I queue them up. I can be. Tony asked me a month ago to set up git tree for OMAP HSMMC and put the workaround for the HSMMC multi-block DMA read corruption there, but hate to admit things have been hanging on todo list. There are some other fixes waiting. Omap_mmc_set_ios() doesn't handle power off case correctly and resume from suspend can hang if the SDBP bit fails to set. Cheers Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
* Jarkko Lavinen jarkko.lavi...@nokia.com [090209 10:06]: Pierre Ossman wrote: Related, who is the maintainer of this driver? Tony? I'd like to have someone who checks patches before I queue them up. I can be. Tony asked me a month ago to set up git tree for OMAP HSMMC and put the workaround for the HSMMC multi-block DMA read corruption there, but hate to admit things have been hanging on todo list. Yeah it would be great if Jarkkko can queue up all the omap MMC patches from now on. There are some other fixes waiting. Omap_mmc_set_ios() doesn't handle power off case correctly and resume from suspend can hang if the SDBP bit fails to set. And then all your PM patches for the next merge window.. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
On Fri, 6 Feb 2009, Jean Pihet wrote: Do you want a finite loop with udelay in it? I located 4 places were this could be used. If so I can generate a new patch for that. Just as an aside, from the standpoint of minimizing CPU usage, there seems little point in using udelay() here, since it is implemented as a CPU busy-wait. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
On Thursday 05 February 2009, Paul Walmsley wrote: + while (OMAP_HSMMC_READ(host-base, + SYSCTL) SRD) + ; Is a __raw_readl() sufficient to prevent the cpu from burning up here, or should we add cpu_relax()? The __raw_readl() should be sufficient. The MMC controller is located on the L4 CORE interconnect, so the round trip latency for the read from MMC is at least 90 ns, while the CPU cycle time is only about 1 to 2 ns. It's still good policy to have a cpu_relax() in such loops. Not that it'll do much on most ARMs, but empty statements are in general worth avoiding. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
On Thursday 05 February 2009 21:32:03 Paul Walmsley wrote: On Thu, 5 Feb 2009, Andrew Morton wrote: On Tue, 3 Feb 2009 15:05:58 +0100 Jean Pihet jpi...@mvista.com wrote: + while (OMAP_HSMMC_READ(host-base, + SYSCTL) SRD) + ; Is a __raw_readl() sufficient to prevent the cpu from burning up here, or should we add cpu_relax()? The __raw_readl() should be sufficient. The MMC controller is located on the L4 CORE interconnect, so the round trip latency for the read from MMC is at least 90 ns, while the CPU cycle time is only about 1 to 2 ns. Ok. An infinite loop which assumes the hardware is perfect is always a worry. But I see the driver already does that, so we're no worse off.. Do you want a finite loop with udelay in it? I located 4 places were this could be used. If so I can generate a new patch for that. - Paul Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
On Fri, 6 Feb 2009 14:22:32 +0100 Jean Pihet jpi...@mvista.com wrote: On Thursday 05 February 2009 21:32:03 Paul Walmsley wrote: On Thu, 5 Feb 2009, Andrew Morton wrote: An infinite loop which assumes the hardware is perfect is always a worry. But I see the driver already does that, so we're no worse off.. Do you want a finite loop with udelay in it? I located 4 places were this could be used. If so I can generate a new patch for that. Even if Andrew doesn't, I'd sure like it. (the finite bit at least) :) Related, who is the maintainer of this driver? Tony? I'd like to have someone who checks patches before I queue them up. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: MMC: replace infinite loops with timeouts (was Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend)
Hi,
On Thu, 5 Feb 2009, Andrew Morton wrote:
An infinite loop which assumes the hardware is perfect is always a
worry. But I see the driver already does that, so we're no worse
off..
Do you want a finite loop with udelay in it? I located 4 places were this
could be used. If so I can generate a new patch for that.
Even if Andrew doesn't, I'd sure like it. (the finite bit at least) :)
Ok here is a patch that replaces the infinite loops with a timeout version.
This patch applies on top of the previous one I sent ('[PATCH] OMAP: MMC:
recover from transfer failures - Resend'). Is that OK?
Related, who is the maintainer of this driver? Tony? I'd like to have
someone who checks patches before I queue them up.
Rgds
From 5ee867d09efe22a903ac7373a05e9e047bad6544 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Fri, 6 Feb 2009 16:42:51 +0100
Subject: [PATCH] OMAP: MMC: replace infinite loops with timeouts
Replace the 'while() ;' with a timeout
Signed-off-by: Jean Pihet jpi...@mvista.com
---
drivers/mmc/host/omap_hsmmc.c | 56
+
1 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1ac6918..7ddc77e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -102,6 +102,8 @@
#define OMAP_MMC_DATADIR_READ 1
#define OMAP_MMC_DATADIR_WRITE 2
#define MMC_TIMEOUT_MS 20
+#define MMC_TIMEOUT_WAIT 100 /* Active wait duration, in usec */
+#define MMC_TIMEOUT_WAIT_LOOPS ((MMC_TIMEOUT_MS * 1000) / MMC_TIMEOUT_WAIT)
#define OMAP_MMC_MASTER_CLOCK 9600
#define DRIVER_NAMEmmci-omap-hs
@@ -384,6 +386,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
struct mmc_omap_host *host = dev_id;
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+ unsigned long timeout_counter;
if (host-cmd == NULL host-data == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
@@ -406,9 +409,17 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base,
SYSCTL) |
SRC);
- while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRC)
- ;
+ timeout_counter = 0;
+ while ((OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRC)
+(timeout_counter++
+
MMC_TIMEOUT_WAIT_LOOPS))
+
udelay(MMC_TIMEOUT_WAIT);
+
+ if (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRC)
+ dev_err(mmc_dev(host-mmc),
+ Timeout waiting on
SRC\n);
host-cmd-error = -ETIMEDOUT;
} else {
@@ -421,9 +432,17 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base,
SYSCTL) | SRD);
- while (OMAP_HSMMC_READ(host-base,
- SYSCTL) SRD)
- ;
+ timeout_counter = 0;
+ while ((OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+(timeout_counter++
+
MMC_TIMEOUT_WAIT_LOOPS))
+ udelay(MMC_TIMEOUT_WAIT);
+
+ if (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ dev_err(mmc_dev(host-mmc),
+ Timeout waiting on SRD\n);
}
}
if ((status DATA_TIMEOUT) ||
@@ -436,9 +455,17 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base,
SYSCTL) | SRD);
- while (OMAP_HSMMC_READ
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
On Tue, 3 Feb 2009 15:05:58 +0100 Jean Pihet jpi...@mvista.com wrote: + while (OMAP_HSMMC_READ(host-base, + SYSCTL) SRD) + ; Is a __raw_readl() sufficient to prevent the cpu from burning up here, or should we add cpu_relax()? An infinite loop which assumes the hardware is perfect is always a worry. But I see the driver already does that, so we're no worse off.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend
On Thu, 5 Feb 2009, Andrew Morton wrote: On Tue, 3 Feb 2009 15:05:58 +0100 Jean Pihet jpi...@mvista.com wrote: + while (OMAP_HSMMC_READ(host-base, + SYSCTL) SRD) + ; Is a __raw_readl() sufficient to prevent the cpu from burning up here, or should we add cpu_relax()? The __raw_readl() should be sufficient. The MMC controller is located on the L4 CORE interconnect, so the round trip latency for the read from MMC is at least 90 ns, while the CPU cycle time is only about 1 to 2 ns. An infinite loop which assumes the hardware is perfect is always a worry. But I see the driver already does that, so we're no worse off.. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: MMC: recover from transfer failures - Resend
Hi,
This is a re-send of the patch that fixes a MMC host controller deadlock. The
problem happens when removing the MMC/SD device when a transfer is on-going.
It has been tested on OMAP3430 but this fix should apply to OMAP2 chips as
well, as seen from the TRMs.
Regards,
Jean
From d143f6b2e705aa4e9d2b032097fd1c82f8163262 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Thu, 8 Jan 2009 12:35:21 +0100
Subject: [PATCH] OMAP: MMC: recover from transfer failures
Timeouts during a command that has a data phase can result in the
next command issued after the command that failed not being processed,
i.e. no interrupt ever occurs to indicate the command has completed.
This failure can result in a deadlock.
This patch resets the data state machine to clear the error in
case of a command timeout.
Tested on OMAP3430 chip and intensive MMC/SD device removal while
transferring data.
Signed-off-by: Andy Lowe al...@mvista.com
Signed-off-by: Jean Pihet jpi...@mvista.com
Signed-off-by: Adrian Hunter ext-adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c | 9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5c1e9d..97150c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -464,8 +464,15 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
end_cmd = 1;
}
- if (host-data)
+ if (host-data) {
mmc_dma_cleanup(host);
+ OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRD);
+ while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ ;
+ }
}
if ((status DATA_TIMEOUT) ||
(status DATA_CRC)) {
--
1.5.4.4.21.gc4a6c
On Monday 02 February 2009 20:05:06 Tony Lindgren wrote:
Hi,
* Jean Pihet jpi...@mvista.com [090202 00:46]:
Tony,
Has this patch been applied to the linux-omap tree? Does it need to go
the patchwork?
Cf. http://marc.info/?l=linux-omapm=123141577308177w=2
I'm not applying MMC patches, we need to move that discussion to LKML
and keep Pierre involved.
Jarkko Lavinen was planning to set up a git branch against the mainline
tree for the omap mmc patches, so until we have that, let's just let the
patches float on the list for a while.
But yeah, if you want patchwork to pick up your patch so it does not
get lost, just please resend it to the linux-omap list and it should
get automatically picked up by patchwork.
Regards,
Tony
From d143f6b2e705aa4e9d2b032097fd1c82f8163262 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Thu, 8 Jan 2009 12:35:21 +0100
Subject: [PATCH] OMAP: MMC: recover from transfer failures
Timeouts during a command that has a data phase can result in the
next command issued after the command that failed not being processed,
i.e. no interrupt ever occurs to indicate the command has completed.
This failure can result in a deadlock.
This patch resets the data state machine to clear the error in
case of a command timeout.
Tested on OMAP3430 chip and intensive MMC/SD device removal while
transferring data.
Signed-off-by: Andy Lowe al...@mvista.com
Signed-off-by: Jean Pihet jpi...@mvista.com
Signed-off-by: Adrian Hunter ext-adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5c1e9d..97150c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -464,8 +464,15 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
end_cmd = 1;
}
- if (host-data)
+ if (host-data) {
mmc_dma_cleanup(host);
+OMAP_HSMMC_WRITE(host-base, SYSCTL,
+ OMAP_HSMMC_READ(host-base,
+ SYSCTL) | SRD);
+while (OMAP_HSMMC_READ(host-base,
+ SYSCTL) SRD)
+ ;
+ }
}
if ((status DATA_TIMEOUT) ||
(status DATA_CRC)) {
--
1.5.4.4.21.gc4a6c
