Hi Konstantin, On Sun, Nov 20, 2011 at 5:12 PM, Konstantin Dorfman <kdorfman@xxxxxxxxxxxxxx> wrote: > Hello Per, > >> On Thu, Nov 17, 2011 at 4:01 PM, Konstantin Dorfman >> <kdorfman@xxxxxxxxxxxxxx> wrote: >>> Hello Jaenhoon, >>> >>> I have a few suggestions regarding the situation when Host starts BKOPS: >>> >>> 1) Host should start BKOPS (based on BKOPS_STATUS or URGENT_BKOPS event) >>> when going to mmc_sleep, which means that the bus is in idle state (this >>> also covers the case in mmc_queue_thread, because in this case no I/O >>> request exists). It seems like checking the status periodically in >>> addition >>> to mmc_suspend is not needed. Since if the device was in idle and we >>> performed a single BKOPS then there is no point in performing another >>> BKOPS >>> unless there was actually another I/O request. >>> >>> 2) Also this implies an answer to the question about need to interrupt >>> BKOPS >>> before powering off card - the answer is no. >> By the answer no you mean there is no risk of data corruption if >> cutting power in the middle of a BKOPS. When the card is powered up >> next time it will verify that bkops is in a defined state, and do >> recovery if necessary. An interesting comment I got from Sebastian is >> if this recovery mechanism affects card boot time. >> The question is: May the card boot up slower (due to recovery) next >> time if BKOPS was ongoing at power off? >> I assume this recovery time should be insignificant, but I don't know for >> sure. >> > Let me explain proposed flow: > The only trigger to start BKOPS command should be mmc_power_off() function, > just before sending POWER_OFF_NOTIFICATION[34] and only when BKOPS is needed > (by needed I understand situation, when URGENT_BKOPS event arrived or > BKOPS_STATUS 0x2 or 0x3). > The flow will wait till BKOPS successfully completed and than continue to > powering off the card. Power off will never occur in the middle of BKOPS. > Also do not need to start BKOPS when mmc_queue_thread() is in IDLE state > (no requests exists), because in such case power off should be done to card. > I wonder how this works with suspend. If suspend is called on the system, MMC should suspend quickly and not wait for the BKOPS to finish. For pm_runtime_suspend it's fine to return -EBUSY and defer pm_runtime_suspend until BKOPS is completed. mmc_power_on/off is too low level I think. What about adding this at the suspend/resume level instead? >>> 3) Based on statistical data we have (day long test) it looks like we do >>> not >>> need to do any preventive BKOPS caused by BKOPS_STATUS less than >>> critical >>> (0x3). >> I proposed this "preventive action" but at that time I didn't have any >> data to back it up with. I've run some day long tests and what I could >> see is when BKOPS_LEVEL goes from 0 to 1, it goes back to 0 without >> having to start BKOPS. Can you confirm this with your tests as well? >> One explanation I got for this is that level of 1 only means the eMMC >> internal cache is fragmented and not the actual memory. > We have such data from card vendors, but I plan to do similar tests to > confirm. > I will update about the results. Looking forward to see your results. Thanks, Per -- 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
