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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
