>-----Original Message----- >From: linux-mmc-owner@xxxxxxxxxxxxxxx >[mailto:linux-mmc-owner@xxxxxxxxxxxxxxx] On Behalf Of Andrei Warkentin >Sent: Thursday, April 14, 2011 8:04 AM >To: linux-mmc@xxxxxxxxxxxxxxx >Cc: arnd@xxxxxxxx; cjb@xxxxxxxxxx; Gao, Yunpeng >Subject: Re: SET_BLOCK_COUNT-bounded multiblock transfers > >On Wed, Apr 13, 2011 at 7:38 PM, Andrei Warkentin ><andreiw@xxxxxxxxxxxx> wrote: >> This is a request for comments for a patch set that enables >> predefined multiblock transfers if these are supported. >> >> Before this patch set, all multiblock transfers look like (for example) >> >> CMD25 -> [block] [block] [block] [block] -> CMD12 (stop) >> >> ...or for controllers with Auto-CMD12 >> >> CMD25 -> [block] [block] [block] [block] (host sends CMD12 itself). >> >> We want to enable - >> >> CMD23(4 blocks) CMD25 [data] [data] [data] [data] >> >> ...and for controllers with Auto-CMD23 - >> >> (Host sends CMD23(4 blocks)) CMD25 [data] [data] [data] [data] >> >> The interrupt overhead is the same, but for cards that optimize for >predefined transfers >> we can see better transfer rates. I've tested this on a Sandisk eMMC where I >saw as good as >> a 50% improvement on writes, and on a Toshiba eMMC where I saw no >improvement at all. Also, >> reliable writes use CMD23, so this cleans up that code path as well. Note, >that if a transfer >> fails, CMD12 must still be sent, so it is not sufficient to just not fill the >mrq->stop field >> while doing a CMD23-enabled transfer. Due to this error handling and >off-loads of Auto-CMD23 >> (and interaction with Auto-CMD12) handling of SET_BLOCK_COUNT, just like >STOP, is left to the host driver. >> Host driver now exposes MMC_CAP_CMD23 if it has been changed to >handle the new "sbc" field in struct mmc_request. >> If a host doesn't expose this capability, open-ended transfers are used, and >all functionality >> relying on CMD23 (such as reliable writes) is disabled. >> >> The third patch has been only tested on SD cards that don't expose CMD23. >Still need to get an SDXC >> card and test it out, but I wanted to get eyes on this patch set anyway :-). >> >> I had a fourth patch enabling Auto-CMD23 for SDHCI, but I'll hold off until I >can verify it. >> >> Thoughts? >> >> Table of Contents: >> [RFC 1/3] MMC: use CMD23 for multiblock transfers when we can. >> [RFC 2/3] MMC: Implement MMC_CAP_CMD23 for SDHCI. >> [RFC 3/3] MMC: Block CMD23 support for UHS104/SDXC cards. >> >> A >> > >+ Yunpeng 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. Regards, Yunpeng -- 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
