Re: [patch 4/5] MMC OMAP driver

From: Pierre Ossman
Date: Tue Jan 31 2006 - 10:09:08 EST


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 <tony@xxxxxxxxxxx>
>

> @@ -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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/