Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1491679 > unrolled thread
| Started by | Ritesh Harjani <riteshh@codeaurora.org> |
|---|---|
| First post | 2016-09-27 06:50 +0200 |
| Last post | 2016-09-27 06:50 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support Ritesh Harjani <riteshh@codeaurora.org> - 2016-09-27 06:50 +0200
| From | Ritesh Harjani <riteshh@codeaurora.org> |
|---|---|
| Date | 2016-09-27 06:50 +0200 |
| Subject | Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support |
| Message-ID | <slSv7-50g-1@gated-at.bofh.it> |
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 >
Back to top | Article view | linux.kernel
csiph-web