[...]

quoted

quoted

quoted

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.

quoted

Regards,
Pramod

Kind regards
Uffe