On Fri, Nov 11, 2011 at 9:42 AM, Dong, Chuanxiao <chuanxiao.dong@xxxxxxxxx> wrote: > > >> -----Original Message----- >> From: Per Forlin [mailto:per.lkml@xxxxxxxxx] >> Sent: Friday, November 11, 2011 4:32 PM >> To: Dong, Chuanxiao >> Cc: Jaehoon Chung; linux-mmc; Jae hoon Chung; Chris Ball; Kyungmin Park; >> Hanumath Prasad; Sebastian Rasmussen; svenkatr@xxxxxx >> Subject: Re: [PATCH v2] mmc: support BKOPS feature for eMMC >> >> On Fri, Nov 11, 2011 at 8:48 AM, Per Forlin <per.lkml@xxxxxxxxx> wrote: >> > On Fri, Nov 11, 2011 at 7:51 AM, Dong, Chuanxiao >> > <chuanxiao.dong@xxxxxxxxx> wrote: >> >> Hi Jaehoon, >> >> >> >>> -----Original Message----- >> >>> From: Jaehoon Chung [mailto:jh80.chung@xxxxxxxxxxx] >> >>> Sent: Wednesday, November 02, 2011 6:29 PM >> >>> To: linux-mmc >> >>> Cc: Chris Ball; Kyungmin Park; Hanumath Prasad; Sebastian Rasmussen; Per >> Forlin; >> >>> svenkatr@xxxxxx; Dong, Chuanxiao >> >>> Subject: [PATCH v2] mmc: support BKOPS feature for eMMC >> >>> >> >>> 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. >> >>> >> >>> Signed-off-by: Jaehoon Chung <jh80.chung@xxxxxxxxxxx> >> >>> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> >> >>> CC: Hanumath Prasad <hanumath.prasad@xxxxxxxxxxxxxx> >> >>> >> >>> --- >> >>> Changelog V2: >> >>> - Use EXCEPTION_STATUS instead of URGENT_BKOPS >> >>> - Add function to check Exception_status(for eMMC4.5) >> >>> - remove unnecessary code. >> >>> >> >>> drivers/mmc/card/block.c | 9 +++++ >> >>> drivers/mmc/card/queue.c | 4 ++ >> >>> drivers/mmc/core/core.c | 87 >> >>> ++++++++++++++++++++++++++++++++++++++++++++ >> >>> drivers/mmc/core/mmc.c | 9 ++++- >> >>> drivers/mmc/core/mmc_ops.c | 4 ++ >> >>> include/linux/mmc/card.h | 12 ++++++ >> >>> include/linux/mmc/core.h | 3 ++ >> >>> include/linux/mmc/host.h | 1 + >> >>> include/linux/mmc/mmc.h | 14 +++++++ >> >>> 9 files changed, 142 insertions(+), 1 deletions(-) >> >>> >> >>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c >> >>> index a1cb21f..fbfb405 100644 >> >>> --- a/drivers/mmc/card/block.c >> >>> +++ b/drivers/mmc/card/block.c >> >>> @@ -1192,6 +1192,15 @@ static int mmc_blk_issue_rw_rq(struct >> mmc_queue >> >>> *mq, struct request *rqc) >> >>> case MMC_BLK_SUCCESS: >> >>> case MMC_BLK_PARTIAL: >> >>> /* >> >>> + * Check BKOPS urgency from each R1 response >> >>> + */ >> >>> + if (mmc_card_mmc(card) && >> >>> + (brq->cmd.resp[0] & >> R1_EXCEPTION_EVENT)) { >> >>> + if (mmc_is_exception_event(card, >> >>> >> + EXT_CSD_URGENT_BK >> OPS)) >> >>> >> + mmc_card_set_need_bkops(card >> ); >> >>> + } >> >>> + /* >> >> Have you thought about moving this into mmc_wait_for_req_done()? We can >> check if the command is a R1 or R1B or not, and set BKOPS bit in there if needed. I >> was just thinking if we put such code here, we may only cover the successful >> scenario but not for the failed cases. Putting in mmc_wait_for_req_done can cover >> all cases. >> >> >> > Good point! I'm in favor of this change. >> Or, put the check before the switch-case. > If we put in mmc_wait_for_req_done, then we can catch all R1 response command result not only for the READ/WRITE command, right? Yes I agree. The only reason for _not_ moving it to wait_for_req_done() would be if this response (URGENT_BKOPS) is directly connected to request handled by mmc_blk_issue_rw_rq() and no one else. I don't know the answer. >ERASE command is also using R1 response. I wasn't aware of this. Reading the R1 response should be done in wait_for_req_done(). Checking if the response is (URGENT_BKOPS) could still be done in mmc_blk_issue_rw_rq(), if this particular response only happens here. Otherwise that needs to be done in wait_for_req_done() too. 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
