Re: [PATCH V4 01/15] mmc: host: Add facility to support re-tuning

[Adrian Hunter <adrian.hunter@intel.com>]

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.