From: Jaehoon Chung <jh80.chung@samsung.com>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: Venkatraman S <svenkatr@ti.com>,
linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
Subject: Re: [PATCH v2] mmc: core: Fix the HPI execution sequence
Date: Wed, 18 Apr 2012 10:40:40 +0900 [thread overview]
Message-ID: <4F8E1B98.1050803@samsung.com> (raw)
In-Reply-To: <CAKYAXd96A6yzaz-59y+79sgRaQuT3MpRBZKStJM4HQN3L-=h5A@mail.gmail.com>
On 04/18/2012 09:20 AM, Namjae Jeon wrote:
> 2012/4/17 Venkatraman S <svenkatr@ti.com>:
>> mmc_execute_hpi should send the HPI command only
>> once, only if the card is in PRG state.
>>
>> According to eMMC spec, the command's completion time is
>> not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
>> out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
>> defined to begin at the end of sending the command itself.
> Hi. Venkatraman.
> I can not find this words. " the command's completion time is not
> dependent on OUT_OF_INTERRUPT_TIME" .
> Would you inform me which page and which part you checked in specification ?
Well, i know that timeout value is used the OUT_OF_INTERRUPT_TIME, when interrupted by HPI.
It's my misunderstanding?
Best Regards,
Jaehoon Chung
>
> Thanks.
>>
>> Specify the default timeout for the actual sending of HPI
>> command, and then use OUT_OF_INTERRUPT_TIME to wait for
>> the transition out of PRG state.
>>
>> Reported-by: Alex Lemberg <Alex.Lemberg@sandisk.com>
>> Signed-off-by: Venkatraman S <svenkatr@ti.com>
>> CC: Namjae Jeon <linkinjeon@gmail.com>
>> CC: Jae hoon Chung <jh80.chung@gmail.com>
>> CC: Chris Ball <cjb@laptop.org>
>> ---
>> Changes since v1:
>> Skip looping over send_status indefinitely
>> Correct the interpretation of OUT_OF_INTERRUPT_TIME
>>
>> drivers/mmc/core/core.c | 45 ++++++++++++++++++++++++--------------------
>> drivers/mmc/core/mmc_ops.c | 2 +-
>> 2 files changed, 26 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index e541efb..027c579 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
>> {
>> int err;
>> u32 status;
>> + unsigned long starttime;
>>
>> BUG_ON(!card);
>>
>> @@ -421,27 +422,31 @@ int mmc_interrupt_hpi(struct mmc_card *card)
>> /*
>> * If the card status is in PRG-state, we can send the HPI command.
>> */
>> - if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
>> - do {
>> - /*
>> - * We don't know when the HPI command will finish
>> - * processing, so we need to resend HPI until out
>> - * of prg-state, and keep checking the card status
>> - * with SEND_STATUS. If a timeout error occurs when
>> - * sending the HPI command, we are already out of
>> - * prg-state.
>> - */
>> - err = mmc_send_hpi_cmd(card, &status);
>> - if (err)
>> - pr_debug("%s: abort HPI (%d error)\n",
>> - mmc_hostname(card->host), err);
>> + if (R1_CURRENT_STATE(status) != R1_STATE_PRG) {
>> + pr_debug("%s: Can't send HPI: Card state=%d\n",
>> + mmc_hostname(card->host), R1_CURRENT_STATE(status));
>> + err = -EINVAL;
>> + goto out;
>> + }
>> +
>> + starttime = jiffies;
>> + err = mmc_send_hpi_cmd(card, &status);
>> + if (err) {
>> + pr_debug("%s:HPI could not be sent.err=%d)\n",
>> + mmc_hostname(card->host), err);
>> + goto out;
>> + }
>> +
>> + do {
>> + err = mmc_send_status(card, &status);
>> +
>> + if (!err && R1_CURRENT_STATE(status) == R1_STATE_TRAN)
>> + goto out;
>> + if (jiffies_to_msecs(jiffies - starttime) >
>> + card->ext_csd.out_of_int_time)
>> + err = -ETIMEDOUT;
>> + } while (!err);
>>
>> - err = mmc_send_status(card, &status);
>> - if (err)
>> - break;
>> - } while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
>> - } else
>> - pr_debug("%s: Left prg-state\n", mmc_hostname(card->host));
>>
>> out:
>> mmc_release_host(card->host);
>> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
>> index 69370f4..f2235d6 100644
>> --- a/drivers/mmc/core/mmc_ops.c
>> +++ b/drivers/mmc/core/mmc_ops.c
>> @@ -569,7 +569,7 @@ int mmc_send_hpi_cmd(struct mmc_card *card, u32 *status)
>>
>> cmd.opcode = opcode;
>> cmd.arg = card->rca << 16 | 1;
>> - cmd.cmd_timeout_ms = card->ext_csd.out_of_int_time;
>> + cmd.cmd_timeout_ms = 0;
>>
>> err = mmc_wait_for_cmd(card->host, &cmd, 0);
>> if (err) {
>> --
>> 1.7.10.rc2
>>
>
next prev parent reply other threads:[~2012-04-18 1:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 13:45 [PATCH v2] mmc: core: Fix the HPI execution sequence Venkatraman S
2012-04-18 0:20 ` Namjae Jeon
2012-04-18 1:40 ` Jaehoon Chung [this message]
2012-04-18 4:45 ` Namjae Jeon
2012-04-18 6:20 ` S, Venkatraman
2012-04-18 8:23 ` Namjae Jeon
2012-04-18 8:42 ` S, Venkatraman
2012-04-18 12:54 ` Jaehoon Chung
2012-04-18 14:49 ` S, Venkatraman
2012-04-18 14:45 ` [PATCH] " Venkatraman S
2012-04-18 23:03 ` Namjae Jeon
2012-04-19 1:52 ` Jaehoon Chung
2012-04-19 4:22 ` S, Venkatraman
2012-04-19 4:25 ` Chris Ball
2012-04-19 4:43 ` [PATCH v2] " Venkatraman S
2012-04-19 13:35 ` Chris Ball
2012-04-19 13:43 ` S, Venkatraman
2012-04-19 14:38 ` Venkatraman S
2012-05-09 13:17 ` kdorfman
2012-05-09 13:53 ` S, Venkatraman
2012-05-09 14:06 ` kdorfman
2012-05-09 14:12 ` S, Venkatraman
2012-05-10 15:08 ` kdorfman
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=4F8E1B98.1050803@samsung.com \
--to=jh80.chung@samsung.com \
--cc=cjb@laptop.org \
--cc=linkinjeon@gmail.com \
--cc=linux-mmc@vger.kernel.org \
--cc=svenkatr@ti.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.