On Mon, May 30, 2011 at 3:32 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Mon, May 30, 2011 at 10:01 AM, Daniel Drake <dsd@xxxxxxxxxx> wrote: >> On 30 May 2011 07:52, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: >>> Last we talked, we found out runtime PM didn't work because the sd8686 >>> required an additional manipulation of an external reset gpio line, >>> and that the only reason OLPC could power it down/up was this patch: >>> >>> http://dev.laptop.org/git/olpc-2.6/commit/?h=olpc-2.6.35&id=e9bee721fb0cc303286d1fe5df4930ce79b0b1e0 >> >> My further investigation here suggests that this change is not >> necessary. It was added in response to a separate (hard-to-reproduce) >> issue and it was never known if it would actually fix that issue, it >> was more of a guess. We don't have any convincing evidence that it >> helps, so it will be dropped in future. >> >> Anyway, just to be sure, I tried combining this hack with runtime PM, >> and also as a regulator, and it didn't help anything. runtime PM still >> fails to power up the card. >> >> Sorry for leading you down the wrong path there. > ... >>> does mmc_stop_host+mmc_start_host >>> work for you without manipulating that reset gpio ? >> >> Yes. > > Hm. I still don't entirely get it, because we had others (Mike, cc'd) > saying too that the sd8686 requires manipulating an external reset > gpio after bringing the power back up. sd8686 requires two pins to control power, PDn and RESETn. To enable sd8686, PDn and RESETn should both set high. To disable sd8686, PDn should be set low. We also have plans to use runtime PM to optimize these two pins, suggested by Ohad before. However currently we still use rfkill method to control the two pins. In the stress test, we found wlan card may not be probed successfully even the two pins are set correctly, so we manually detect whether mmc->card is allocated or not, not sure whether runtime PM to handle this case. > > Maybe someone from Marvell can comment on this (cc'ing Zhangfei Gao) ? > >> You didn't comment on the added mmc_select_voltage() call. Is that one >> also sensible? > > I guess. if we're reading the I/O OCR, might as well use it. This way > our runtime PM power up path will also be identical to the one induced > by mmc_attach_sdio. > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
