From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751636AbcI0Ekp (ORCPT ); Tue, 27 Sep 2016 00:40:45 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60891 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750816AbcI0Ekg (ORCPT ); Tue, 27 Sep 2016 00:40:36 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 4A3456159A 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: Ulf Hansson References: <20160901142335.2396-1-pramod.gurav@linaro.org> <496321c5-24e7-3ac5-b3dd-7b7d5dc75536@linaro.org> Cc: Pramod Gurav , Georgi Djakov , Adrian Hunter , linux-mmc , "open list:ARM/QUALCOMM SUPPORT" , open list , Stephen Boyd From: Ritesh Harjani Message-ID: <14564525-bb35-ca13-7a7c-b408df4a09ed@codeaurora.org> Date: Tue, 27 Sep 2016 10:10:28 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.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 Ulf, On 9/23/2016 3:37 PM, Ulf Hansson wrote: > [...] > >>>>> 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. > > I see. > > I assumes that means saving/restoring register context will > automatically handled by some other outer logic, when doing clock > gating/ungating? > > In other words, if the controller has valid tuning values, those will > be re-used and restored when clock ungating happens? Yes, that is my understanding too. I double confirmed with HW team about this. So, even if we gate the clock directly at GCC, sdhc msm controller is capable of restoring it's register values. In this case, it is not required to call for sdhci_runtime_suspend/resume from sdhci_msm_runtime routines right? Instead we can only have disabling/enabling of clks from sdhci_msm_runtime_suspend/resume. Does this sounds good? > >> >> >> 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 >>> >> > > 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 >