[...] >>>> 1) Card removal/detect (hold/release?) >>> >>> Re-tuning will be done if needed before detect (because it is done before a >>> request), which is necessary because detect can fail if tuning is needed. >>> >>> Re-tuning is done before a request. Requests aren't started if the card has >>> been removed i.e. mmc_start_request() calls mmc_card_removed() >>> >>> If tuning is executed while a card is being removed, then the tuning will >>> fail and the request will be errored out. >> >> So you are saying that we instead of relying on the CMD13 (for SD/MMC) >> to check whether the card is still alive, it's fine to trigger a >> re-tuning instead. > > (Oops forgot to answer this one, sorry) > > Yes, why not? > >> >> I don't think that is an effective way to remove a card. > > Generally we know the card is removed from card-detect so no commands are > sent in either case. Not sure what you mean here. In case when the card is "idle" and the host sees a GPIO CD irq, it will trigger a detect work to run mmc_rescan(). In this case, it's the responsibility of mmc_rescan() to find out if the card is being removed. It does so by invoking the bus_ops->detect() callback, which eventually will send a CMD13 for mmc/sd. In this scenario, I can't see why we want to allow re-tuning to happen in front of the CMD13 command. > >> >> Moreover, I find it quite unreasonable to say the check for an alive >> card, would fail because of that a re-tuning is needed. That would in >> principle mean that we never should be able to hold re-tune for any >> commands sequences. > > Re-tuning must work if the card is alive. CMD13 might get a CRC error if > re-tuning is needed. And that then applies to all commands which we hold re-tuning for. So then we can't _ever_ hold re-tuning for any command, since we might get CRC errors. 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
