On Tue, Jul 24, 2012 at 7:26 AM, Jaehoon Chung <jh80.ch...@samsung.com> wrote: > Enable eMMC background operations (BKOPS) feature. > > If URGENT_BKOPS is set after a response, note that BKOPS > are required. Immediately run BKOPS if required. > read/write operations should be requested during BKOPS(LEVEL-1), > then issue HPI to interrupt the ongoing BKOPS > and service the foreground operation. > (This patch is only control the LEVEL2/3.) > > When repeating the writing 1GB data, at a certain time, performance is > decreased. > At that time, card is also triggered the Level-3 or Level-2. > After running bkops, performance is recovered. > > Future considerations > * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner. > * Interrupt ongoing BKOPS before powering off the card. > * How get BKOPS_STATUS value.(periodically send ext_csd command?) > * If use periodic bkops, also consider runtime_pm control. > > Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com> > Signed-off-by: Kyungmin Park <kyungmin.p...@samsung.com> > Signed-off-by: Konstantin Dorfman <kdorf...@codeaurora.org> > Signed-off-by: Maya Erez <me...@codeaurora.org>
I've tested this patch and it works as intended, except that it is causing a data read/write abort on my OMAP board with BKOPS enabled eMMC. But the fault is on the host controller side which has an upper limit on the timeout value that can be set for the command, which is too short for the maximum advertised BKOPS execution time. I need to fix omap_hsmmc to disable DTO for BKOPS as an exception (just like it's done for ERASE today) or an equivalent fix. Other host controllers also have to check this. Regards, Venkat. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
