[...] >> If/when you decide to fix this issue. Please keep in mind the following >> things. >> >> - Try to convert the SDHCI into a pure library. No more quirks or callbacks. >> - I assume we can simplify lots of code if we convert SDHCI into using >> a threaded IRQ in favour of the tasklet. >> >> Any patches that moves SDHCI into this direction will be greatly appreciated! > > Ok, this sounds like a good way to go. Unfortunately it also sounds like a > major endeavor, for which good knowledge of the SDHCI standard is necessary. > This knowledge is based on documentation that is not openly available without > cost AFAIK. This probably also explains why there hasn't been a real fix ever. > On top of that, the whole sdhci code is unmaintained currently as it seems. > I was studying the code a bit more, and I now understand that I am not even > close to having the experience and standards-knowledge it takes to pull this > off reliably. I guess the one who takes on this task may as well become > official maintainer afterwards... You are right, a maintainer is needed for sdhci. Also, I am a bit surprised that none have stepped up, especially since it's indeed being *very* widely used. > OTOH, we pretty much depend on this driver now, since all of our new i.MX6/7 > boards have eMMC flash. We also use the flexcan peripheral on all designs, > which is specially sensible to these latency spikes, so we will have to do > something on the long run.... we cannot live forever with disabled PM ;-) > Unfortunate, PM is only one of the problems. The code is in general fragile. We have have kind of reached the point, when I apply changes that fixes one issue it may cause another. 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
