From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH V6 03/15] mmc: core: Add support for re-tuning before each request Date: Wed, 6 May 2015 12:37:52 +0200 Message-ID: References: <1429531796-21987-1-git-send-email-adrian.hunter@intel.com> <1429531796-21987-4-git-send-email-adrian.hunter@intel.com> <5549CA93.5010803@intel.com> <5549EA2A.3020309@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-qc0-f172.google.com ([209.85.216.172]:32781 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751277AbbEFKhx (ORCPT ); Wed, 6 May 2015 06:37:53 -0400 Received: by qctx5 with SMTP id x5so2185904qct.0 for ; Wed, 06 May 2015 03:37:52 -0700 (PDT) In-Reply-To: <5549EA2A.3020309@intel.com> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Adrian Hunter Cc: linux-mmc , Aaron Lu , Philip Rakity , Al Cooper , Arend van Spriel On 6 May 2015 at 12:17, Adrian Hunter wrote: > On 06/05/15 12:45, Ulf Hansson wrote: >> On 6 May 2015 at 10:02, Adrian Hunter wrote: >>> On 04/05/15 16:28, Ulf Hansson wrote: >>>> On 20 April 2015 at 14:09, Adrian Hunter 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 >>>> >>>> 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