Re: SET_BLOCK_COUNT-bounded multiblock transfers

[Andrei Warkentin <andreiw@motorola.com>]

On Thu, Apr 14, 2011 at 4:05 AM, Gao, Yunpeng <yunpeng.gao@intel.com> 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