From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934236AbcIVOcv (ORCPT ); Thu, 22 Sep 2016 10:32:51 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:42980 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933343AbcIVOcs (ORCPT ); Thu, 22 Sep 2016 10:32:48 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 0027B612D3 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=riteshh@codeaurora.org Subject: Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support To: Pramod Gurav , Ulf Hansson References: <20160901142335.2396-1-pramod.gurav@linaro.org> <496321c5-24e7-3ac5-b3dd-7b7d5dc75536@linaro.org> Cc: Georgi Djakov , Adrian Hunter , linux-mmc , "open list:ARM/QUALCOMM SUPPORT" , open list , Stephen Boyd From: Ritesh Harjani Message-ID: Date: Thu, 22 Sep 2016 20:02:41 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pramod, On 9/15/2016 7:28 PM, Pramod Gurav wrote: > On 15 September 2016 at 15:49, Ulf Hansson wrote: >> On 15 September 2016 at 09:59, Pramod Gurav wrote: >>> On 9 September 2016 at 15:48, Georgi Djakov wrote: >>>> On 09/08/2016 11:02 AM, Adrian Hunter wrote: >>>>> >>>>> On 01/09/16 17:23, Pramod Gurav wrote: >>>>>> >>>>>> Provides runtime PM callbacks to enable and disable clock resources >>>>>> when idle. Also support system PM callbacks to be called during system >>>>>> suspend and resume. >>>>>> >>>>>> Signed-off-by: Pramod Gurav >>>>> >>>>> >>>>> Can we get some Tested/Reviewed/Acked-by from people using this driver? >>>>> >>>> >>>> Hi Pramod, >>>> Thanks for the patch. Unfortunately, my db410c board fails to >>>> boot when i apply it. >>>> >>> >>> Thanks Georgi for testing the patch. Its my wrong I did not update my >>> kernel and continued fixing comments on old kernel. >>> After spending some time I came to know that below change is causing the issue: >>> >>> Author: Dong Aisheng >>> Date: Tue Jul 12 15:46:17 2016 +0800 >>> >>> mmc: sdhci: add standard hw auto retuning support >>> >>> If HW supports SDHCI_TUNING_MODE_3 which is auto retuning, we won't >>> retune during runtime suspend and resume, instead we use Re-tuning >>> Request signaled via SDHCI_INT_RETUNE interrupt to do retuning and >>> hw auto retuning during data transfer to guarantee the signal sample >>> window correction. >>> >>> This can avoid a mass of repeatedly retuning during small file system >>> data access and improve the performance. >>> >>> Specially these lines that was added to suspend path: >>> >>> + if (host->tuning_mode != SDHCI_TUNING_MODE_3) >>> + mmc_retune_needed(host->mmc); >>> >>> During sdhci setup in msm driver, the host returns the values to set >>> sdhci auto tuning as supported. >>> Hence host->tuning_mode is set to SDHCI_TUNING_MODE_3 during setup. >>> But some how the auto tuning is not happening. >>> Just to verify my case, I removed the 'if' part in above code and got >>> the FS mounted. >>> >>> Is there anything else needed in msm sdhci driver so that the auto >>> tuning is taken care of? >> >> I am not familiar with any other than sdhci-esdhc-imx which supports >> the SDHCI_TUNING_MODE_3. I may be wrong though. >> >> In the sdhci-esdhc-imx case, enabling of auto tuning seems to be done >> in esdhc_post_tuning(), where a vendor specific register >> (ESDHC_MIX_CTRL) is being written to. Perhaps something similar in >> your case? >> > Thanks Ulf for the comments. Will check this and see if there is > something of this sort we have to do to achieve auto tuning. > Adding Ritesh who has been posting some SDHCI MSM patches recently in > case he knows about this. Internally, we don't use this Auto re-tuning and rely on explicit re-tune by host driver. Question though - 1. why do we need to call sdhci_runtime_resume/suspend from sdhci_msm_runtime_suspend/resume? From what I see is, sdhci_runtime_susend/resume will do reset and re-program of host->pwr and host->clk because of which a retune will be required for the next command after runtime resume. We can *only* disable and enable the clocks in sdhci_msm_runtime_suspend/resume? Thoughts? With this, I suppose you would not see any issue. Though for this issue, since internally also auto retuning is never used, we can have this mode disabled. I can once again check with HW team to get more details about this mode for MSM controller. > > Regards, > Pramod >