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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[...]

>>>>>>>>> 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.

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.

I know, it's a bit of a vague idea so I will give it some more
thinking during the Easter holidays.

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




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux