| Message ID | 5549EA2A.3020309@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 6 May 2015 at 12:17, Adrian Hunter <adrian.hunter@intel.com> wrote: > On 06/05/15 12:45, Ulf Hansson wrote: >> On 6 May 2015 at 10:02, Adrian Hunter <adrian.hunter@intel.com> wrote: >>> On 04/05/15 16:28, Ulf Hansson wrote: >>>> On 20 April 2015 at 14:09, Adrian Hunter <adrian.hunter@intel.com> 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@intel.com> >>>> >>>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; }