[...] >>> Thank you for looking at the patches. >>> >>> I am not sure I know what you mean. sdhci already has a re-tuning timer, so >>> this is just moving it into core, where it won't be used by other drivers >>> unless they enable it. >> >> I am kind of questioning the re-tuning timer in sdhci. What is it good for? > > It is part of the SD Host Controller Standard Specification. The timer > ensures that re-tuning is done before temperature changes could affect the > "sampling point". It is needed for re-tuning mode 1 for UHS-I modes like > SDR104.
Does the spec say what value the timer should have? > >> >> Can sdhci rely on that the mmc core performs a re-tune from the >> request retry mechanism instead? > > Not according to the standard. We don't have to implement everything that comes with the standard. We can leave things out. > >> >>> >>> I am not sure what you want to leave in sdhci.c and what you want in core, >>> if anything. >> >> We need all the infrastructure code in the core. Much like what your >> patchset does. Except that I would like you to remove the option of >> having a timer and the corresponding complexity it adds. > > If we are going to follow the standard then that doesn't seem to be an option. I am not suggestion us to violating the spec. I am suggesting to currently not support all of it. > >> >>> >>> At a minimum I need sdhci to be able to switch from hs400 to hs200, re-tune, >>> and switch back. >> >> As stated, I am only questioning the timer, nothing else. > > Ok so how should I proceed? > As I stated, let's try without the timer first. If we find it's not enough to recover at the request retry path, since it happens too often - lets deal with that then. Okay? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
