[...] >>>> 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? > > > 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-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
