public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: merez@codeaurora.org
To: Jaehoon Chung <jh80.chung@samsung.com>
Cc: merez@codeaurora.org, linux-mmc <linux-mmc@vger.kernel.org>,
	Chris Ball <cjb@laptop.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Konstantin Dorfman <kdorfman@codeaurora.org>,
	"svenkatr@ti.com" <svenkatr@ti.com>,
	Saugata Das <saugata.das@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@stericsson.com>,
	Per FORLIN <per.forlin@stericsson.com>,
	Hanumath Prasad <hanumath.prasad@stericsson.com>,
	Sebastian Rasmussen <sebras@gmail.com>,
	"Dong, Chuanxiao" <chuanxiao.dong@intel.com>
Subject: Re: [RESEND PATCH v10] mmc: support BKOPS feature for eMMC
Date: Mon, 23 Jul 2012 02:14:52 -0700 (PDT)	[thread overview]
Message-ID: <c169f4ac2e5c9f2c40571b03f45b34ab.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <500CA8AA.5090704@samsung.com>

Hi Jaehoon,

I don't have additional comments.

Thanks,
Maya
On Sun, July 22, 2012 6:28 pm, Jaehoon Chung wrote:
> Hi Maya,
>
> On 07/20/2012 08:58 PM, merez@codeaurora.org wrote:
>>
>> On Thu, July 19, 2012 8:12 am, Jaehoon Chung wrote:
>>> +void mmc_start_bkops(struct mmc_card *card, bool from_exception)
>>> +{
>>> +        int err;
>>> +        int timeout;
>>> +        bool use_busy_signal;
>>> +
>>> +        BUG_ON(!card);
>>> +
>>> +        if (!card->ext_csd.bkops_en || mmc_card_doing_bkops(card) ||
>>> +                !(card->host->caps2 & MMC_CAP2_BKOPS))
>>> +                return;
>> To my opinion, the host cannot decide not to support BKOPs if it is
>> enabled by the card. In such a case, the card will expect the host to
>> start the BKOPs and may get into performance degradation.
>> I think the MMC_CAP2_BKOPS should be removed.
>> Does everyone agree or do I miss something?
> Ok..i will remove capability. I saw that other people agreed your opinion.
>>
>>> @@ -489,6 +568,53 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct
>>> mmc_command *cmd, int retries
>>>  EXPORT_SYMBOL(mmc_wait_for_cmd);
>>>
>>>  /**
>>> + *	mmc_stop_bkops - stop ongoing BKOPS
>>> + *	@card: MMC card to check BKOPS
>>> + *
>>> + *	Send HPI command to stop ongoing background operations,
>>> + *	to allow rapid servicing of foreground operations,e.g. read/
>>> + *	writes. Wait until the card comes out of the programming state
>>> + *	to avoid errors in servicing read/write requests.
>>> + */
>>> +int mmc_stop_bkops(struct mmc_card *card)
>>> +{
>>> +	int err = 0;
>>> +
>>> +	BUG_ON(!card);
>>> +	err = mmc_interrupt_hpi(card);
>>> +
>>> +	/*
>>> +	 * if err is EINVAL, it's status that can't issue HPI.
>>> +	 * it should complete the BKOPS.
>>> +	 */
>>> +	if (!err || (err == -EINVAL)) {
>>> +		mmc_card_clr_doing_bkops(card);
>>> +		err = 0;
>>> +	}
>> I don't understand the comment regarding the case where err equals
>> -EINVAL. Can you please explain it?
> When err is -EINVAL, already completed bkops.
> After completed bkops, should be the trans status.
> If my understanding is wrong, let me know.
>>
>>> @@ -392,13 +393,25 @@ int mmc_switch(struct mmc_card *card, u8 set, u8
>>> index, u8 value,
>>>                    (index << 16) |
>>>                    (value << 8) |
>>>                    set;
>>> -        cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
>>> +        cmd.flags = MMC_CMD_AC;
>>> +        if (use_busy_signal)
>>> +                cmd.flags |= MMC_RSP_SPI_R1B | MMC_RSP_R1B;
>>> +        else
>>> +                cmd.flags |= MMC_RSP_SPI_R1 | MMC_RSP_R1;
>>> +
>>> +
>>>          cmd.cmd_timeout_ms = timeout_ms;
>>>
>>>          err = mmc_wait_for_cmd(card->host, &cmd, MMC_CMD_RETRIES);
>>>          if (err)
>>>                  return err;
>>>
>>> +        /*
>>> +         * No need to check card status in case of BKOPS LEVEL1 switch
>>> +         */
>>
>> Change the comment to be general (don't mention BKOPs level 1),
>> something
>> like:
>> No need to check card status in case of unblocking command.
>> Also, 1 line comment should be /* comment */
> Will fix.
>
> Any other comment? if you have other comment, let me know.
> I will send the patch after fixing on today.
>
> Best Regards,
> Jaehoon Chung
>>
>> Thanks,
>> Maya
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Sent by consultant of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum


      reply	other threads:[~2012-07-23  9:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19 15:12 [RESEND PATCH v10] mmc: support BKOPS feature for eMMC Jaehoon Chung
2012-07-20 11:58 ` merez
2012-07-20 12:57   ` Adrian Hunter
2012-07-23  1:28   ` Jaehoon Chung
2012-07-23  9:14     ` merez [this message]

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=c169f4ac2e5c9f2c40571b03f45b34ab.squirrel@www.codeaurora.org \
    --to=merez@codeaurora.org \
    --cc=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox