On 13/04/15 15:07, Ulf Hansson wrote: > On 8 April 2015 at 09:42, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >> On 02/04/15 17:00, Ulf Hansson wrote: >>> [...] >>> >>>>>>>>>>>> Also SDIO cards can have a custom sleep state where tuning won't work. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Our SDIO wifi device has such a state and it can only come out of it >>>>>>>>>>> upon >>>>>>>>>>> CMD52 write or CMD14 (ExitSleep). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So how will the mmc core know about these states? I guess we will >>>>>>>>>> require SDIO func drivers to deal with enable/disable or hold/release >>>>>>>>>> of re-tuning then? >>>>>>>>> >>>>>>>>> >>>>>>>>> This is actually why in the past we tried to only kick off retuning >>>>>>>>> before a >>>>>>>>> request that requires use of data line(s) so mmc core (or sdhci) would not >>>>>>>>> do re-tuning when SDIO func used CMD52 to wakeup the device. I never tried >>>>>>>>> CMD14 approach and not even sure from which spec it comes (maybe eMMC). >>>>>>>> >>>>>>>> That's an interesting idea. It would eliminate the need for SDIO func >>>>>>>> drivers to care about holding/releasing re-tuning. >>>>>>>> >>>>>>>> Would be nice to hear about Adrian's thoughts around this as well. >>>>>>> >>>>>>> I don't see how it would work because re-tuning is needed after the host >>>>>>> controller runtime resumes. i.e. once the SDIO wifi card stops being active >>>>>>> the host controller will runtime suspend. >>>>>> >>>>>> Why do we always need to re-tune from this phase? >>>>>> >>>>>> What Arend points out is that we could "delay" the re-tune until we >>>>>> know there is a DATA request. Wouldn't that work for SDHCI as well? >>>>> >>>>> You beat me to it, but that is indeed what I meant. >>>> >>>> The CMD line needs tuning too, so delaying tuning on every command will >>>> cause errors. It is better to hold tuning for the specific command used to >>>> wake-up. >>> >>> Hmm. >>> >>> This touches the discussion where Neil Brown also was involved, around >>> how to handle "idle operations" for SDIO. >>> >>> How does SDIO func drivers detects "request inactivity", which >>> triggers them to send its device to "sleep mode"? That answer should >>> be runtime PM. >> >> 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. > > 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. -- 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
