On Fri, 16 Oct 2020 at 14:50, Michael Walle <michael@xxxxxxxx> wrote: > > Am 2020-10-16 12:53, schrieb Ulf Hansson: > > On Fri, 16 Oct 2020 at 01:12, Michael Walle <michael@xxxxxxxx> wrote: > >> > >> On rare occations there is the following error: > >> > >> mmc0: Tuning timeout, falling back to fixed sampling clock > >> > >> There are SD cards which takes a significant longer time to reply to > >> the > >> first CMD19 command. The eSDHC takes the data timeout value into > >> account > >> during the tuning period. The SDHCI core doesn't explicitly set this > >> timeout for the tuning procedure. Thus on the slow cards, there might > >> be > >> a spurious "Buffer Read Ready" interrupt, which in turn triggers a > >> wrong > >> sequence of events. In the end this will lead to an unsuccessful > >> tuning > >> procedure and to the above error. > >> > >> To workaround this, set the timeout to the maximum value (which is the > >> best we can do) and the SDHCI core will take care of the proper > >> timeout > >> handling. > >> > >> Signed-off-by: Michael Walle <michael@xxxxxxxx> > > > > Sound like this should be tagged for stable, right? > > Yes, but I was unsure about that. I didn't find a lot of Fixes: tags in > the history of this driver (eg. for errata etc.) > > I could repost a v2 with a fixes tag if you like. If this is regression and you can point to a specific commit it fixes, then please yes! Kind regards Uffe
