On 17/11/11 02:50, Jaehoon Chung wrote:
> Enable eMMC background operations (BKOPS) feature.
>
> If URGENT_BKOPS is set after a response, note that BKOPS
> are required. After all I/O requests are finished, run
> BKOPS if required. Should read/write operations be requested
> during BKOPS, first issue HPI to interrupt the ongoing BKOPS
> and then service the request.
>
> If you want to enable this feature, set MMC_CAP2_BKOPS.
>
> Future considerations
> * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
> * Interrupt ongoing BKOPS before powering off the card.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@xxxxxxxxxxx>
> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
> CC: Hanumath Prasad <hanumath.prasad@xxxxxxxxxxxxxx>
> ---
> Changelog V3:
> - move the bkops setting's location in mmc_blk_issue_rw_rq
> - modify condition checking
> - bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of "1"
> - remove the unused code
> - change pr_debug instead of pr_warn in mmc_send_hpi_cmd
> - Add the Future consideration suggested by Per
>
> Changelog V2:
> - Use EXCEPTION_STATUS instead of URGENT_BKOPS
> - Add function to check Exception_status(for eMMC4.5)
> - remove unnecessary code.
>
The main problem with bkops is:
If the status is at level 3 ("critical"), some operations
may extend beyond their original timeouts due to maintenance
operations which cannot be delayed anymore.
This means:
1. at level 3 either bkops are run or the timeout of the next
(data?) operation is extended
2. at level 3 either the bkops must not be interrupted or the
level must be rechecked after interruption and bkops run again
if the level is still 3
--
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
