On Wed, Apr 6, 2011 at 10:33 AM, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote: > On Wed, Apr 6, 2011 at 8:54 AM, Gao, Yunpeng <yunpeng.gao@xxxxxxxxx> wrote: >> Currently, the mmc driver uses open ended multiple block read/write (CMD18/25+CMD12) commands and not use pre-defined multiple block read/write (CMD23+CMD18/25) commands. >> >> According to the feedback from some MMC/SD device vendors, they prefer the pre-defined multiple block read/write commands since it gives the device a chance to do some internal optimization. >> >> Also I found on the latest eMMC 4.5 Spec, quite a few new features requires using of CMD23. That means, these new features can not be implemented with the open ended multiple block read/write commands. >> >> So, the question is, why the current mmc driver does not use the pre-defined multiple block read/write commands? Any comments? >> > > While I really don't know, I would guess becase the SD spec has a > different definition of ACMD23 than MMC, so perhaps avoiding > ACMD/CMD23 that was chosen as the simpler more common alternative. > Alternatively, the difference might imply that at one time it was an > optional feature. I'll try digging up an early MMCA spec to confirm... Ok let me correct myself. For SD: ACMD23 - SET_WR_BLK_ERASE_COUNT might speed to the multiple write block, but still need CMD12 after the write. CMD23 - optional and mandatory on UHS104 cards. CMD23 support is noted in SCR register. > > At least one new MMC feature now (reliable writes) requires CMD23, and > at the very least using SET_BLOCK_COUNT instead of STOP_TRANSMISSION > would make that code path more homogenous. Certainly the overhead is > the same for MMC - either send an extra command before or after the > transfer. For SD you do get an extra CMD55 before CMD23, since it's > ACMD23 we're talking about. > > I am actually working on a patch to do just that... > Which I will send shortly. 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
