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

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

On 02/04/15 15:10, Ulf Hansson wrote:
> On 2 April 2015 at 12:30, Arend van Spriel <arend@broadcom.com> wrote:
>> On 04/02/15 10:43, Ulf Hansson wrote:
>>>
>>> [...]
>>>>>>>
>>>>>>>     - ability to hold off re-tuning if the card is busy
>>>>>>
>>>>>>
>>>>>>
>>>>>> What do you mean by "card is busy"?
>>>>>
>>>>>
>>>>>
>>>>> I guess, more accurately, any time the card is in a state that is
>>>>> incapable
>>>>> of supporting re-tuning. For example:
>>>>>          - DAT0 busy
>>>>
>>>>
>>>>
>>>> This state is not specific to re-tuning. An SDIO device can keep DAT0
>>>> busy
>>>> at which the host controller can not start another request.
>>>
>>>
>>> Not entirely true. Some commands are allowed during this period, for
>>> example CMD13 (which doesn't exist for SDIO)
>>
>>
>> Yeah. I was wondering whether to mention that.
>>
>>> Anyway, I get the point. Thanks!
>>>
>>>>
>>>>>          - between dependent commands like erase start, end, etc
>>>>>          - card is asleep
>>>>> 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.

Also I would expect doing re-tuning before every data request would likely
be unacceptable from a performance point of view.

> 
>>
>>> I don't like this, but if there is no other way... Also, we must be
>>> very careful on which API we exports for SDIO func drivers to use. The
>>> can easily be misinterpreted.
>>>
>>> [...]
> 
> Kind regards
> Uffe
> 
>