On Fri, Jul 22, 2011 at 1:42 AM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 19/07/2011 7:48 p.m., Chris Ball wrote: >> >> Hi, >> >> On Tue, Jul 19 2011, S, Venkatraman wrote: >>> >>> On Wed, Jul 13, 2011 at 8:06 PM, Balaji T K<balajitk@xxxxxx> wrote: >>>> >>>> Put MMC to sleep if it supports SLEEP/AWAKE (CMD5) >>>> in the mmc suspend to minimize power consumption. >>>> >>>> Signed-off-by: Balaji T K<balajitk@xxxxxx> >>> >>> Balaji, >>> Would you mind reposting the patch without the RFC and s/CORE/core >>> in subject line ? >>> You can add my >>> Acked-by: Venkatraman S<svenkatr@xxxxxx> >> >> No need to resend, thanks -- pushed to mmc-next with these changes and >> the ACK. >> >> Anyone object to letting this soak in mmc-next for a release and merging >> it in 3.2? I'm worried that we'll find card or host quirks around this, >> and the 3.0 release is probably happening today. > > eMMC often have VccQ (logic) always on (or sharing the same power as SDRAM > which comes to the same thing), but can switch off Vcc (NAND core). > However, turning off Vcc without first putting the card to sleep can result > in errors i.e. you are not allowed to do it. > > This patch seems to be covering the "VccQ always on" case but relies on CMD0 > to wake up the card. > > If that is what is going on, then some comments to that effect are needed, > including within mmc_init_card to note that mmc_go_idle is needed for cards > that are asleep - if that is, in fact, correct. Yes, current implementation depends on CMD0 in mmc_init_card to wakeup. Specification allows eMMC card in sleep to respond to CMD0/CMD5 Will send an updated patch with comments added. > > Also, wouldn't it be nice to wake up the card with CMD5 which should be much > faster than re-initialising? > >> - Chris. > > -- 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
