On 04/02/15 14:25, Ulf Hansson wrote:
On 2 April 2015 at 14:18, Adrian Hunter<adrian.hunter@xxxxxxxxx> wrote:
On 02/04/15 15:10, Ulf Hansson wrote:
On 2 April 2015 at 12:30, Arend van Spriel<arend@xxxxxxxxxxxx> 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.
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.
Regards,
Arend
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
--
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
