Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

Ulf Hansson
2015-01-14T12:59:35Z

[...]

>>
>> The value from the register is also just randomly selected, only
>> difference is that it's the HW that has randomly set it.
>
> Presumably the value is chosen based on the maximum rate of temperature
> change and the corresponding effect that has on the signal.
>
>>
>> Even if the above commit was merged, I don't think it was the correct
>> way of dealing with re-tuning.
>>
>> First of all, re-tuning this is a mmc protocol specific thing should
>> be managed from the mmc core, like the approach you have taken in your
>> $subject patchset. Second I question whether the timer is useful at
>> all.
>
> The SD Host Controller Specification does not document another way to do
> mode 1 re-tuning. The timer is it. Otherwise re-tuning is never done.
>
> In the patches I sent, the driver must call mmc_retune_needed() to set
> host->need_retune = 1 otherwise mmc_retune() does nothing.
>
> I would like to extend the model to include transparently re-tuning and
> re-trying when there is a CRC error, but that is a separate issue, not
> documented in the spec but recommended by others.
>

That perfect and in line from what I heard as recommendations from
memory vendors as well.

Now, can we stop arguing about the timer and try without it?

If we do see a need for a more frequent re-tuning to happen, due to
that we get lots of CRC errors to recover from, then I think we should
look into using runtime PM instead of the timer. And that's because I
want to minimize the impact on performance.

Kind regards
Uffe