On 6 May 2015 at 10:02, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 04/05/15 16:28, Ulf Hansson wrote: >> On 20 April 2015 at 14:09, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >>> At the start of each request, re-tune if needed and >>> then hold off re-tuning again until the request is done. >>> >>> Note that though there is one function that starts >>> requests (mmc_start_request) there are two that wait for >>> the request to be done (mmc_wait_for_req_done and >>> mmc_wait_for_data_req_done). Also note that >>> mmc_wait_for_data_req_done can return even when the >>> request is not done (which allows the block driver >>> to prepare a newly arrived request while still >>> waiting for the previous request). >>> >>> This patch ensures re-tuning is held for the duration >>> of a request. Subsequent patches will also hold >>> re-tuning at other times when it might cause a >>> conflict. >>> >>> Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx> >> >> Patch2 is calling mmc_retune_needed() and thus actually triggers a >> re-tune to potentially happen. > > That won't happen because host->retune_period is not set, so > mmc_retune_needed() won't be called. mmc_retune_needed() is indeed called in patch2 (v7). From mmc_sdio_suspend() and when mmc_card_keep_power(). I guess that wont be an issue!? But I just felt that it seemed more appropriate to manage hold/release of re-tune before actually enabling the feature. 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