On Fri, Jun 17, 2011 at 4:58 PM, Daniel Drake <dsd@xxxxxxxxxx> wrote: > Ignore the probe error - just observe the fact that the card was > detected and powered on, powered off, powered on and *then* probed. This is the normal behavior today when drivers are probed: we power up the card before probing a driver, and if the probe fails, we power it off. To be exact, we're not even doing that deterministically. We are powering off the *SDIO function*, and not the card. I once changed this to be deterministic, but didn't pursue this eventually, because frankly it's not hugely important. > That's the same thing that happens in the resume path. You mean on *libertas'* resume path, which doesn't really do suspend/resume - it just removes the card, and let it be re-probed later. > Couldn't the > power have just been maintained from when the card was detected, given > that the driver was loaded and ready to go? Most cards wouldn't care too much: we're not loading/unloading drivers too frequently, and the advantage of the current solution is simplicity. But you are welcome to change this if you need to. I don't see how it can hurt anyone, and anyway it can also happen today too in some cases. > 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? I agree that a 250ms delay on the power up path is way too long. But let's first try to understand what's the real problem it is solving before picking a solution. This usually pays off, and eventually you'd be happier with the end result. > 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. Use the mailing list :) The Marvell guys were very nice and replied my questions pretty fast. > 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? I'd really prefer to understand what's wrong first. If we have a rigid hardware requirement that demands waiting before powering it up again, then we better obey it. But I somehow doubt that a 250ms delay is required. That's way too much... 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
