On 5 September 2014 11:29, Jaehoon Chung <[email protected]> wrote: > Hi, Ulf. > > On 09/03/2014 04:32 PM, Ulf Hansson wrote: >> On 3 September 2014 08:51, Dong Aisheng <[email protected]> wrote: >>> Hi Ulf, >>> >>> On Thu, Jan 30, 2014 at 6:37 AM, Ulf Hansson <[email protected]> wrote: >>>> This patchset improves the handling around busy detection in the mmc core >>>> layer >>>> while operating on host supporting MMC_CAP_WAIT_WHILE_BUSY. >>>> >>>> A R1B response is for an mmc command, specified as and R1 but with an >>>> optional >>>> busy assertion on the DAT0 line. Hosts supporting MMC_CAP_WAIT_WHILE_BUSY, >>>> normally has a busy detection mechanism build in it's controller HW. >>>> >>>> Using such a feature decreases the need for polling of the card's status >>>> using >>>> CMD13, which is the fallback method used by the mmc core for hosts that >>>> don't >>>> support MMC_CAP_WAIT_WHILE_BUSY. >>>> >>>> Typcial commands that expects R1B responses are CMD6 (SWITCH), CMD12 >>>> (STOP), >>>> CMD38 (ERASE) and CMD5 (SLEEP). This patchset adresses CMD6, CMD5 and >>>> improves >>>> some parts where CMD12 are used. If the implemented approach becomes >>>> accepted, >>>> a future patchset for CMD38 can be based on top if this patchset. >>>> >>>> Do note, the final two patches implements support for busy detection for >>>> the >>>> mmci host driver, since some of it's HW variants do supports busy >>>> detection. >>>> >>>> Future suggested improvements related to this patchset: (Please, feel free >>>> to >>>> implement any of them :-) ). >>>> >>>> a) For CMD38, select a fixed number maximum blocks to accept for >>>> erase/discard/trim operations. Compute the needed timeout depending on each >>>> card's erase information provided through it's CSD/EXT_CSD registers. Then >>>> follow the same principle as for sending a CMD6. >>>> >>>> b) At least for CMD38, but likely for other commands as well, we could >>>> benefit >>>> from doing a _periodic_ CMD13 polling to handle the busy completion. This >>>> will >>>> also be useful for hosts supporting MMC_CAP_WAIT_WHILE_BUSY, in particular >>>> for >>>> cases where the host are unable to support the needed busy timeout. >>>> >>> >>> Do you have the plan to implement above two items? >> >> Yes, it's on top of my TODO list for MMC. I really need to get this >> done asap. Thanks for pinging me about this. >> >>> Since currently the max_discard_sectors is still calculated based on >>> max_busy_timeout of host, >>> it is possible that for some eMMC chips, the max_discard_sectors is 1, >>> which then cause the erase operation terribly slow. >> >> Yes! >> >> Another issue to fix is get MMC_CAP_ERASE removed - and that should be >> possible once the above described problem has been solved. > > Did you send the patch V2 for this patch-set?
I assume you refer to: [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY All those patches has been merged, but can't remember how many iterations of them we required though. :-) Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
