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).
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
Regards,
Arend
--
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
