Some MMC cards don't set the R1_READY_FOR_DATA bit if EOFB
interrupt comes first. In this case we need to mask R1_READY_FOR_DATA
to avoid polling card status forever.
This patch needs to be discussed as it requires interface change.
This interface change is done here only for omap for now.
Signed-off-by: Tony Lindgren <[email protected]>
Index: linux-2.6.15-mmc_omap/drivers/mmc/mmc_block.c
===================================================================
--- linux-2.6.15-mmc_omap.orig/drivers/mmc/mmc_block.c 2006-01-26 16:57:08.000000000 -0400
+++ linux-2.6.15-mmc_omap/drivers/mmc/mmc_block.c 2006-01-26 17:04:52.000000000 -0400
@@ -218,6 +218,10 @@ static int mmc_blk_issue_rq(struct mmc_q
goto cmd_err;
}
+ /* No need to check card status after a read */
+ if (rq_data_dir(req) == READ)
+ goto card_ready;
+
do {
int err;
@@ -239,6 +243,8 @@ static int mmc_blk_issue_rq(struct mmc_q
if (mmc_decode_status(cmd.resp))
goto cmd_err;
#endif
+
+card_ready:
/*
* A block was successfully transferred.
*/
@@ -336,6 +342,7 @@ static struct mmc_blk_data *mmc_blk_allo
card_ready:
+card_ready:
/*
* As discussed on lkml, GENHD_FL_REMOVABLE should:
*
Index: linux-2.6.15-mmc_omap/drivers/mmc/omap.c
===================================================================
--- linux-2.6.15-mmc_omap.orig/drivers/mmc/omap.c 2006-01-26 16:57:11.000000000 -0400
+++ linux-2.6.15-mmc_omap/drivers/mmc/omap.c 2006-01-26 16:57:11.000000000 -0400
@@ -319,7 +319,7 @@ mmc_omap_dma_done(struct mmc_omap_host *
}
static void
-mmc_omap_cmd_done(struct mmc_omap_host *host, struct mmc_command *cmd)
+mmc_omap_cmd_done(struct mmc_omap_host *host, struct mmc_command *cmd, int card_ready)
{
host->cmd = NULL;
@@ -332,6 +332,9 @@ mmc_omap_cmd_done(struct mmc_omap_host *
cmd->resp[0] =
OMAP_MMC_READ(host->base, RSP6) |
(OMAP_MMC_READ(host->base, RSP7) << 16);
+ if (card_ready) {
+ cmd->resp[0] |= R1_READY_FOR_DATA;
+ }
break;
case MMC_RSP_LONG:
/* response type 2 */
@@ -428,6 +431,7 @@ static irqreturn_t mmc_omap_irq(int irq,
u16 status;
int end_command;
int end_transfer;
+ int card_ready;
int transfer_error;
if (host->cmd == NULL && host->data == NULL) {
@@ -442,6 +446,7 @@ static irqreturn_t mmc_omap_irq(int irq,
end_command = 0;
end_transfer = 0;
+ card_ready = 0;
transfer_error = 0;
while ((status = OMAP_MMC_READ(host->base, STAT)) != 0) {
@@ -542,10 +547,19 @@ static irqreturn_t mmc_omap_irq(int irq,
(!(status & OMAP_MMC_STAT_A_EMPTY))) {
end_command = 1;
}
+ /* Some cards produce EOFB interrupt and never
+ * raise R1_READY_FOR_DATA bit after that.
+ * To avoid infinite card status polling loop,
+ * we must fake that bit to MMC layer.
+ */
+ if ((status & OMAP_MMC_STAT_END_OF_CMD) &&
+ (status & OMAP_MMC_STAT_END_BUSY)) {
+ card_ready = 1;
+ }
}
if (end_command) {
- mmc_omap_cmd_done(host, host->cmd);
+ mmc_omap_cmd_done(host, host->cmd, card_ready);
}
if (transfer_error)
mmc_omap_xfer_done(host, host->data);
Anderson Briglia wrote:
> Some MMC cards don't set the R1_READY_FOR_DATA bit if EOFB
> interrupt comes first. In this case we need to mask R1_READY_FOR_DATA
> to avoid polling card status forever.
> This patch needs to be discussed as it requires interface change.
> This interface change is done here only for omap for now.
>
> Signed-off-by: Tony Lindgren <[email protected]>
>
> @@ -336,6 +342,7 @@ static struct mmc_blk_data *mmc_blk_allo
>
> card_ready:
>
> +card_ready:
> /*
> * As discussed on lkml, GENHD_FL_REMOVABLE should:
> *
This chunk seems incorrect.
> @@ -542,10 +547,19 @@ static irqreturn_t mmc_omap_irq(int irq,
> (!(status & OMAP_MMC_STAT_A_EMPTY))) {
> end_command = 1;
> }
> + /* Some cards produce EOFB interrupt and never
> + * raise R1_READY_FOR_DATA bit after that.
> + * To avoid infinite card status polling loop,
> + * we must fake that bit to MMC layer.
> + */
> + if ((status & OMAP_MMC_STAT_END_OF_CMD) &&
> + (status & OMAP_MMC_STAT_END_BUSY)) {
> + card_ready = 1;
> + }
> }
>
> if (end_command) {
> - mmc_omap_cmd_done(host, host->cmd);
> + mmc_omap_cmd_done(host, host->cmd, card_ready);
> }
> if (transfer_error)
> mmc_omap_xfer_done(host, host->data);
This sounds highly suspicious. Have you tried the card on another
controller? I do not like this mix of fixing it both in the driver and
in the MMC layer. Either it's a hardware issue and should be fixed in
the driver, or it's a generic problem and should be fixed in the MMC layer.
Rgds
Pierre