On 16 June 2011 22:22, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Thu, Jun 16, 2011 at 8:27 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: >> Why is there so much power flipping going on during resume? > > There isn't. > > You see this with libertas, because it doesn't really suspend/resume cleanly. It's not related to suspend/resume. If I build libertas_sdio into the kernel I see the same thing happening during boot: http://dev.laptop.org/~dsd/20110617/dmesg.txt [ 3.023445] mmc1: new SDIO card at address 0001 [ 3.039597] mmc_power_save_host mmc1 [ 3.054897] mmc_power_restore_host mmc1 [ 3.409482] CMD5 reset failed, err=-110 [ 3.427733] libertas_sdio: probe of mmc1:0001:1 failed with error -16 Ignore the probe error - just observe the fact that the card was detected and powered on, powered off, powered on and *then* probed. That's the same thing that happens in the resume path. Couldn't the power have just been maintained from when the card was detected, given that the driver was loaded and ready to go? > Could you also trigger this with the previous power off/on mechanism > you used (an rfkill driver IIRC) ? if not, what's the difference ? did > you have just enough delay there which didn't trigger this problem ? No, it couldn't be triggered. This is because our rfkill driver used the "normal" MMC card powerup routine (which runtime PM doesn't use) which unconditionally calls sdio_reset(). Thinking more, I think I prefer sdio_reset() as a quirk/workaround instead of the sleep, because the sleep is quite long. What do you think? > First, I suggest to understand where does this requirement come from. > Is this a rigid hardware requirement ? Does it always require waiting > 250ms before powering it on again ? Any suggestions for how I go about doing that? Unfortunately we have a backlog of support requests with Marvell which have not yet been responded to. > If yes, then why not let the relevant regulator take care of it ? this > way you never have to care. you just power it off and on as you > please, and things just work. Yes, a regulator could work. But, aren't regulators linked to the platform rather than to the card? I would imagine that this quirk needs to be applied to all users of the card, therefore a card quirk could be more appropriate? Also, if you think the sdio_reset() option is preferable to the sleep, can that be done from a regulator? Thanks Daniel -- 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
