Re: [PATCH 3/3] mmc: sdhci: Disable re-tuning for HS400

Ulf Hansson
2014-12-02T14:06:19Z

On 2 December 2014 at 13:28, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 02/12/14 13:20, Ulf Hansson wrote:
>> On 2 December 2014 at 11:08, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>> On 02/12/14 11:35, Ulf Hansson wrote:
>>>> On 1 December 2014 at 14:16, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>>> Re-tuning for HS400 mode must be done in HS200
>>>>> mode. Currently there is no support for that.
>>>>> That needs to be reflected in the code.
>>>>> Specifically, if tuning is executed in HS400 mode
>>>>> then return an error, and if the re-tuning timer
>>>>> is running when switching to HS400 mode, then
>>>>> disable the timer.
>>>>>
>>>>> Note that periodic re-tuning is not expected
>>>>> to be needed for HS400 but re-tuning is still
>>>>> needed after the host controller has lost power.
>>>>
>>>> Why can't the old values be restored instead of trigger a re-tuning?
>>>
>>> The "values" (not sure what you mean by that) are not available to the
>>> driver. Even if they were the operating conditions may have changed, (i.e.
>>> temperature change) so the old "values" could still be wrong.
>>
>> The "values" I refer to is those which we "calculated" during the
>> tuning process.
>>
>> What I had in mind, was that we should save these values at runtime PM
>> suspend. And restore them at runtime PM resume. For some mmc
>> controllers the "values" are typically just a some bits in a
>> controller register, but that might not be true for all cases.
>>
>> Regarding the temperature change, etc. I think that is what the
>> periodic retuning should be taken care off.
>>
>> Could you elaborate on why the "values" is not available to the driver?
>
> The "optimal sampling point" has no corresponding register or value
> in SDHCI.

Is that really the case for all sdhci variants? For sure I am not an
sdhci expert, but I just find it to be a very poor HW design.

Especially if the sdhci controller may lose power frequently, it will
add a significant latency for each runtime PM resume cycle, right!?

Anyway, thanks for sharing the information.

Kind regards
Uffe