[...] >>> >>> 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. 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. Kind regards Uffe -- 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
