Hi Daniel, On Sun, May 29, 2011 at 7:21 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: > It's certainly possible that there's something weird about the > hardware in question, but we *are* able to successfully power down and > up the card with a hacky rfkill driver that calls mmc_stop_host / > mmc_start_host. Are we talking about the XO-1.5 and the sd8686 ? 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 One of the suggested solutions back then was to use a regulator for this. Has anything changed since then ? does mmc_stop_host+mmc_start_host work for you without manipulating that reset gpio ? > err = mmc_send_io_op_cond(host, 0, &ocr); > if (err) > return err; This part actually makes sense. While sending a CMD5 arg=0 is not mandatory when initializing embedded SDIO cards (like the wl12xx is), some cards might still require it, and it is actually anyway required by the spec for removal cards. I just tried it briefly with the wl12xx, and things seems ok. > printk(KERN_WARNING "%s: card claims to support voltages " > "below the defined range. These will be ignored.\n", > mmc_hostname(host)); Please drop this warning though. It was already displayed when mmc_attach_sdio() executed, so the user already knows his card has this thing. With the wl12xx, you'd see this everytime you bring up the interface, so it's really unnecessarily too noisy. > Any thoughts? One other thing to consider is system resume. when wol is disabled, and your chip is powered off during system suspend, you'd need this CMD5 arg=0 in the resume path as well. Some code refactoring should be considered to avoid duplicating this snippet three times though. Otherwise, submit :) Thanks, Ohad. -- 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