[...] >>>> - 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) 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? 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
