Messages in this thread | | | Date | Tue, 31 Jan 2006 16:02:55 +0100 | From | Pierre Ossman <> | Subject | Re: [patch 3/5] MMC OMAP driver |
| |
Anderson Briglia wrote: > Here are some misc fixes we've had in the OMAP tree. Might be worth > testing them on other platforms too. > > Index: linux-2.6.15-mmc_omap/drivers/mmc/mmc.c > =================================================================== > --- linux-2.6.15-mmc_omap.orig/drivers/mmc/mmc.c 2006-01-30 10:24:50.000000000 -0400 > +++ linux-2.6.15-mmc_omap/drivers/mmc/mmc.c 2006-01-30 10:25:19.000000000 -0400 > @@ -704,6 +704,7 @@ static void mmc_power_up(struct mmc_host > int bit = fls(host->ocr_avail) - 1; > > host->ios.vdd = bit; > + host->ios.clock = host->f_min; > host->ios.bus_mode = MMC_BUSMODE_OPENDRAIN; > host->ios.chip_select = MMC_CS_DONTCARE; > host->ios.power_mode = MMC_POWER_UP; > @@ -712,7 +713,6 @@ static void mmc_power_up(struct mmc_host > > mmc_delay(1); > > - host->ios.clock = host->f_min; > host->ios.power_mode = MMC_POWER_ON; > host->ops->set_ios(host, &host->ios); >
Why? What you're doing there is enable the clock at the same time as the power, instead of just the power first. To me, that seems less safe.
> @@ -747,6 +747,7 @@ static int mmc_send_op_cond(struct mmc_h > if (cmd.resp[0] & MMC_CARD_BUSY || ocr == 0) > break; > > + mmc_delay(1); > err = MMC_ERR_TIMEOUT; > > mmc_delay(10);
This seems particularly useless. Probably just a remnant from a separate mmc_delay() addition to the one that's in mainline now.
Rgds Pierre
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |