On 16/04/15 10:24, Ulf Hansson wrote: > [...] > >>>> >>>> Using runtime pm for custom sleep states would seem to conflict with its use >>>> by the power domain. For example ACPI will enumerate embedded SDIO function >>>> devices and link them to the ACPI power domain. Then ACPI will choose the >>>> lowest power state for runtime suspend. >>>> >>>> It isn't obvious how a driver that doesn't know its power domain should >>>> handle runtime pm, other than assuming it means power off. >>> >>> I am not sure what you mean by "power off" in this context. Is that >> >> I guess "power off" is the wrong term. They might have to assume they have >> lost device context. >> >> You should ask the power management mailing list what assumptions a device >> driver can make about the use of runtime pm. If you do, please cc me. >> >>> the power of the actual SDIO card? I don't think so, but I may be >>> wrong. >> >> I was talking about SDIO function devices. > > OK! > >> >>> >>> To enumerate a SDIO card the mmc core first needs to apply power to >>> it. At this point the PM domain isn't yet attached to the SDIO func >>> device (the device doesn't even exist yet) and thus it can't be used >>> to provide power the card. Right? >> >> In the ACPI case the SDIO function device ACPI nodes are children of the >> host controller ACPI node. One possibility is to have the host controller >> driver power on its children. >> >>> >>>> >>>>> >>>>> So, from mmc core perspective we should be able to get notifications >>>>> through runtime PM callbacks (from mmc or sdio bus) to understand >>>>> whether we need to hold of re-tune. >>>> >>>> That doesn't match the requirement. Re-tuning needs to be held for the >>>> wake-up command, not while asleep. >>>> >>> >>> Why should we ever want to re-tune if the card is in a sleep state? >>> Isn't it better to postpone that until it wakes up? >> >> That is what I was saying i.e. hold re-tuning for the wake-up command. >> So if re-tuning is needed it is done after the wake-up command. >> > > Okay. So that means we might be able to use runtime PM from the SDIO > func driver to notify the mmc core through the mmc or sdio bus's > runtime PM callback to understand whether we should hold/allow > re-tune. I don't see how that would work. Only the SDIO function driver knows that tuning can't be done before it's wake-up command. So you still need an API. > > That do requires some additional re-work, both from mmc core point of > view and from SDIO func drivers point of view. I will have a look in > more detail to see if this really is viable. > > The goal from my side is to prevent us from exporting unnecessary APIs > and thus mmc_retune_hold() and mmc_retune_release() could also be > internal functions of the mmc core. That is fine if you have an alternative, but we can't wait forever. -- 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
