All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Jaehoon Chung <jh80.chung@samsung.com>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
	Chris Ball <cjb@laptop.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Hanumath Prasad <hanumath.prasad@stericsson.com>,
	Per FORLIN <per.forlin@stericsson.com>,
	Sebastian Rasmussen <sebras@gmail.com>,
	"Dong, Chuanxiao" <chuanxiao.dong@intel.com>,
	"svenkatr@ti.com" <svenkatr@ti.com>,
	Saugata Das <saugata.das@linaro.org>,
	Konstantin Dorfman <kdorfman@codeaurora.org>,
	Maya Erez <merez@codeaurora.org>,
	Ulf Hansson <ulf.hansson@stericsson.com>
Subject: Re: [PATCH v10] mmc: support BKOPS feature for eMMC
Date: Wed, 18 Jul 2012 09:16:07 +0300	[thread overview]
Message-ID: <500654A7.8010501@intel.com> (raw)
In-Reply-To: <50056176.5010502@samsung.com>

On 17/07/12 15:58, Jaehoon Chung wrote:
> On 07/17/2012 09:30 PM, Adrian Hunter wrote:
>> On 17/07/12 05:44, Jaehoon Chung wrote:
>>
>> <snip>
>>
>>> +/**
>>> + *	mmc_start_bkops - start BKOPS for supported cards
>>> + *	@card: MMC card to start BKOPS
>>> + *
>>> + *	Start background operations whenever requested.
>>> + *	when the urgent BKOPS bit is set in a R1 command response
>>> + *	then background operations should be started immediately.
>>> +*/
>>> +void mmc_start_bkops(struct mmc_card *card)
>>> +{
>>> +	int err;
>>> +	int timeout;
>>> +	u8 use_busy_signal;
>>> +
>>> +	BUG_ON(!card);
>>> +	if (!card->ext_csd.bkops_en || !(card->host->caps2 & MMC_CAP2_BKOPS))
>>> +		return;
>>> +
>>> +	if (mmc_is_exception_event(card, EXT_CSD_URGENT_BKOPS))
>>> +		if (card->ext_csd.raw_bkops_status)
>>> +			mmc_card_set_need_bkops(card);
>>> +
>>> +	/*
>>> +	 * 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);
>>> +	if (card->ext_csd.raw_bkops_status >= EXT_CSD_BKOPS_LEVEL_2) {
>>> +		timeout = MMC_BKOPS_MAX_TIMEOUT;
>>> +		use_busy_signal = 0;
>>> +	} else {
>>> +		timeout = 0;
>>> +		use_busy_signal = 1;
>>> +	}
>>
>> Is this the right way around?
> 
> use the mmc_switch() with R1B..
> this case is no problem, because after sending bkops, repeat the checking card status until prg-done.
> But, at sdhci controller, be occurred data timeout error.
> Because response type is r1b, and timeout value is too large.
> (Actually, i think that is controller's problem..but just its my test environment.)
> 
> if other sdhci controller working well with R1b, use_busy_signal need not.
> Just use the mmc_switch().
> 
> But When running bkops level2/3 use with R1 type, also no problem.
> Because the also checking status in mmc_switch() until prg-done.

You added:

+	/*
+	 * For urgent bkops status (LEVEL_2 and more)
+	 * bkops executed synchronously, otherwise
+	 * the operation is in progress
+	 */
+	if (card->ext_csd.raw_bkops_status < EXT_CSD_BKOPS_LEVEL_2)
+		mmc_card_set_doing_bkops(card);

But:
	status < 2		=> use_busy_signal = 1
	use_busy_signal = 1	=> waiting
	waiting			=> the operation is NOT in progress

Hence my question: Is this the right way around?

Also this change is needed for the addition of 'use_busy_signal' to
mmc_switch:

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index baf90e0..e202a5e 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -417,7 +417,7 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,
                err = mmc_send_status(card, &status);
                if (err)
                        return err;
-               if (card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)
+               if (use_busy_signal && (card->host->caps & MMC_CAP_WAIT_WHILE_BUSY))
                        break;
                if (mmc_host_is_spi(card->host))
                        break;


  reply	other threads:[~2012-07-18  6:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-17  2:44 [PATCH v10] mmc: support BKOPS feature for eMMC Jaehoon Chung
2012-07-17  9:25 ` S, Venkatraman
2012-07-17 10:17   ` Jaehoon Chung
2012-07-17 12:30 ` Adrian Hunter
2012-07-17 12:58   ` Jaehoon Chung
2012-07-18  6:16     ` Adrian Hunter [this message]
2012-07-18  6:31       ` merez
2012-07-17 19:34 merez
2012-07-18  6:42 ` Jaehoon Chung
2012-07-18 17:13   ` merez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500654A7.8010501@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=chuanxiao.dong@intel.com \
    --cc=cjb@laptop.org \
    --cc=hanumath.prasad@stericsson.com \
    --cc=jh80.chung@samsung.com \
    --cc=kdorfman@codeaurora.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=merez@codeaurora.org \
    --cc=per.forlin@stericsson.com \
    --cc=saugata.das@linaro.org \
    --cc=sebras@gmail.com \
    --cc=svenkatr@ti.com \
    --cc=ulf.hansson@stericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.