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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
