On Thu, Apr 14, 2011 at 4:05 AM, Gao, Yunpeng <yunpeng.gao@xxxxxxxxx> wrote: > > Thanks for add me in the loop. I'm fine with the 3 patches. > > And just think that maybe it's not necessary to enable the Auto-CMD23 for SDHCI, > because I have an impression that some Silicon bugs related to Auto-CMD12/Auto-CMD23 > existed in some vendor's SDHCI host controller IP, and I'm not sure they have been fixed or not by now. > That's why I didn't send a patch for that :-). When I get some SDHCI silicon with working Auto-CMD12/Auto-CMD23 I'll come back to that code path. I actually thought about this some more and I decided to decouple CMD23 support and CMD23 use for multiblock writes. Will add a new md->flags bit. This will allow cards where for whatever reason CMD23-bounded transfers are slower to use CMD12 instead, while retaining CMD23 use for things like reliable writes and all those other features you've mentioned that are in the still not public eMMC 4.5. The question to Arnd and Chris - should by default use of CMD23 for multiblock writes be disabled, and enabled per known-good card using add_flag quirk support? Or should CMD23 for multiblock writes be enabled by default, and then disabled for known-bad cards? First approach is safer from the point of view of regressions. People who upgrade to 2.6.40 won't suddenly see worse I/O performance if they have some silicon bugs or if use of CMD23 nullifies some internal optimizations for sequential writes. On the other hand, at some point hopefully everybody fixes their silicon such that CMD23 always means better performance. Thoughts? A -- 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
