[...] >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
