On Fri, Nov 21, 2008 at 5:27 PM, Jarkko Lavinen <jarkko.lavinen@xxxxxxxxx> wrote: > On Fri, Nov 21, 2008 at 04:03:25PM +0200, ext Grazvydas Ignotas wrote: > ... >> Also, HCTL SDVSDET bit will never be set for MMC2 and MMC3, causing >> mentioned omap_mmc_switch_opcond() to be called unconditionally here. >> >> The same block can be found in mmc_omap_detect() function, where it is >> executed on card removal. There it causes MMC2 controller to stop >> working completely on pandora board :( > > TI TRM saus HSMMC2 and HSMMC3 works only with SDVS set to 1.8V in HCTL. > > If the voltage is set to 3.0V and then SDBP (bus power bit) is set, > it is rejected and SDBP remains zero, the controller does nothing and > is seemingly frozen. > > The wrong voltage for MMC2 SDVS is set in omap_mmc_switch_opcond() if > vdd different from 1.8V. > > Also omap_mmc_suspend() set SDVS to 3.0V even for MMC2 and MMC3. When > suspending, everything seemed to work and at resume MMC2 was hung > and failed to detect the card since not even CMD0 was sent. ok, but why there are calls to omap_mmc_switch_opcond() from both omap_mmc_remove() and mmc_omap_detect() at all? This basically causes power and clocks to be turned off, then on, then again off whenever card is or host driver removed. This is probably no big deal, but still. -- 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
