Hi, * Jean Pihet <jpihet@xxxxxxxxxx> [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-omap&m=123141577308177&w=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 > Regards, > Jean > > On Thursday 08 January 2009 12:49:19 Jean Pihet wrote: > > Thanks for the suggestion, it works great (stress tested) and is a cleaner > > fix. > > Here is a patch the latest linux-omap-2.6 tree. Is this OK? > > > > Regards, > > Jean > > > > From d143f6b2e705aa4e9d2b032097fd1c82f8163262 Mon Sep 17 00:00:00 2001 > > From: Jean Pihet <jpihet@xxxxxxxxxx> > > 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 <alowe@xxxxxxxxxx> > > Signed-off-by: Jean Pihet <jpihet@xxxxxxxxxx> > > Signed-off-by: Adrian Hunter <ext-adrian.hunter@xxxxxxxxx> > > --- > > 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 Thursday 08 January 2009 10:02:24 Adrian Hunter wrote: > > > Why not do the reset in mmc_omap_irq() like the other resets? > > > e.g. > > > > > > static irqreturn_t mmc_omap_irq(int irq, void *dev_id) > > > ... > > > if ((status & CMD_TIMEOUT) || > > > (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) ; > > > > > > host->cmd->error = -ETIMEDOUT; > > > } else { > > > host->cmd->error = -EILSEQ; > > > } > > > 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)) { > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
