Hi Konstantin.
Thanks for your comment..
I will consider your opinion and send path-v4...then also let me know
more comments :)
Best Regards,
Jaehoon Chung
2011/12/2 Konstantin Dorfman <kdorfman@xxxxxxxxxxxxxx>:
> Hello Jaehoon,
> After applying your patch and debugging it for some time,
> I want to share my results and suggests some changes to the patch.
> See comments below:
>
>> +void mmc_start_bkops(struct mmc_card *card)
>> +{
>> + int err;
>> + unsigned long flags;
>> +
>> + BUG_ON(!card);
>> + if ((!card->ext_csd.bkops_en) ||
>> + !(card->host->caps2 & MMC_CAP2_BKOPS))
>> + return;
>> +
>> + /*
>> + * If card is already doing bkops or need for
>> + * bkops flag is not set, then do nothing just
>> + * return
>> + */
>> + if (mmc_card_doing_bkops(card)
>> + || !mmc_card_need_bkops(card))
>> + return;
>> +
>> + mmc_claim_host(card->host);
>> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> + EXT_CSD_BKOPS_START, 1, 0);
>> + if (err) {
>> + pr_warning("error %d starting bkops\n", err);
>> + mmc_card_clr_need_bkops(card);
>> + goto out;
>> + }
>> + spin_lock_irqsave(&card->host->lock, flags);
>> + mmc_card_clr_need_bkops(card);
>> + mmc_card_set_doing_bkops(card);
>
> mmc_switch() will use CMD6 with MMC_RSP_R1B flag (see mmc_switch()
> implementation), this flag
> causes mmc controler to wait until busy line (DAT0) released:
>
> ----from eMMC v4.5 protocol----
> 6.12 Responses
> ...
> R1b is identical to R1 with an optional busy signal transmitted on the
> data line DAT0.
> The Device may become busy after receiving these commands based on its
> state prior to the command reception.
> ...
> 7.4.56 BKOPS_START [164]
> Writing any value to this field shall manually start background
> operations. Device shall stay busy till no more
> background operations are needed.
> ----cut----
>
> This means, that mmc_switch() returns only after BKOPS finished by card
> and there is no point
> in setting mmc_card_set_doing_bkops(card). Also, HPI command send to the
> card in order to interrupt BKOPS in mmc_queue_thread()
> will never actually interrupt BKOPS. To resolve this I suggest following:
>
> 1) Define two variants of mmc_switch(...,wait_flag) for BKOPS, where
> wait_flag is true sends CMD6 with MMC_RSP_R1b flag as it happens now.
> wait_flag is false sends CMD6 with MMC_RSP_R1 flag (the only
> difference is MMC_RSP_BUSY bit),
> so the flow continues immediately after CMD response arrives and will
> not wait for busy line release.
>
> 2) The only situation when we want to use synchronous mmc_switch(...,
> true) is URGENT bit arrives from card, in mmc_blk_issue_rw_rq().
> There is no point in waiting for idle time check in mmc_queue_thread(),
> host should start synchronous BKOPS immediately.
>
> 3) When in idle (no requests to issue) we can read BKOPS_STATUS[246] from
> card and depending on state decide:
> 0: nothing to do go idle
> 1: start BKOPS with no wait for busy line ( mmc_switch(..., false))
> and mmc_set_doing_bkops()
> 3&2: start synchronous BKOPS
>
> Let me describe this by pseudo-code below:
>
> queue.c: mmc_queue_thread():
> ...
> req = blk_fetch_request(q)
> if(req == NULL) {
> state = read_bkops_state(); // read BKOPS_STATUS[246] from card
> switch(state) {
> case 0:
> go_idle()
> break;
> case 1:
> start_asynch_bkops() // send CMD6 with no wait for busy
> mmc_set_doing_bkops() // update flag
> break;
> case 2:
> case 3:
> start_synch_bkops() // start CMD6 with wait for busy
> break;
> default:
> go_idle()
> }
> } else {
> if( mmc_doing_bkops() ) {
> mmc_send_hpi()
> mmc_clear_doing_bkops()
> }
> issue(req)
> }
>
> mmc\card\block.c: mmc_blk_issue_rw_rq()
> ...
> if ( (mmc_is_exception_event(card,EXT_CSD_URGENT_BKOPS)) {
> start_synch_bkops() // start CMD6 with wait for busy
> }
> ...
> -----------------------end of pseudo code-------------
>
> Does this make sense?
> Thanks, Kostya
>
>
>
> --
> 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
--
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
