On 6 May 2015 at 12:17, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> On 06/05/15 12:45, Ulf Hansson wrote:
>> 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().
>
> Yes, here is the chunk but it checks host->retune_period which is zero
> because it never gets set.
>
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 5bc6c7d..16e1f39 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -934,8 +934,12 @@ static int mmc_sdio_suspend(struct mmc_host *host)
> mmc_release_host(host);
> }
>
> - if (!mmc_card_keep_power(host))
> + if (!mmc_card_keep_power(host)) {
> mmc_power_off(host);
> + } else if (host->retune_period) {
> + mmc_retune_timer_stop(host);
> + mmc_retune_needed(host);
> + }
>
> return 0;
> }
>
>>
>> I guess that wont be an issue!?
>
> So I don't see an issue.
>
>>
>> But I just felt that it seemed more appropriate to manage hold/release
>> of re-tune before actually enabling the feature.
>
> Yes the feature is gated until setting host->retune_period or calling
> mmc_retune_needed().
>
Okay, fair enough. Let's keep the order of patches as is.
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
