All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Seungwon Jeon <tgih.jun@samsung.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Addy Ke <addy.ke@rock-chips.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Andrew Bresticker <abrestic@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Chris Ball <chris@printf.net>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Sonny Rao <sonnyrao@chromium.org>,
	Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Alexandru Stan <amstan@chromium.org>
Subject: Re: [PATCH] mmc: dw_mmc: Add a timeout for sending CMD11
Date: Fri, 13 Mar 2015 13:38:17 -0700	[thread overview]
Message-ID: <CAD=FV=VcaW3eG49ASWxVV4YgUjiex77Z4ShJV0RJLYh2FEPMsw@mail.gmail.com> (raw)
In-Reply-To: <5502C7CB.3010504@samsung.com>

Jaehoon,

On Fri, Mar 13, 2015 at 4:19 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> Hi Doug.
>
> This patch is a right process. Just i wonder something.
>
> On 03/10/2015 08:18 AM, Doug Anderson wrote:
>> In the Designware databook's description of the "Voltage Switch Normal
>> Scenario" it instructs us to set a timer and fail the voltage change
>> if we don't see the voltage change interrupt within 2ms.  Let's
>> implement that.  Without implementing this I have often been able to
>> reproduce a hang while trying to send CMD11 on an rk3288-based board
>> while constantly ejecting and inserting UHS cards.
>>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> ---
>>  drivers/mmc/host/dw_mmc.c  | 26 ++++++++++++++++++++++++++
>>  include/linux/mmc/dw_mmc.h |  2 ++
>>  2 files changed, 28 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 47dfd0e..d259662 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1020,6 +1020,15 @@ static void __dw_mci_start_request(struct dw_mci *host,
>>
>>       dw_mci_start_command(host, cmd, cmdflags);
>>
>> +     if (cmd->opcode == SD_SWITCH_VOLTAGE) {
>> +             /*
>> +              * Databook says to fail after 2ms w/ no response; give an
>> +              * extra jiffy just in case we're about to roll over.
>> +              */
>> +             mod_timer(&host->cmd11_timer,
>> +                       jiffies + msecs_to_jiffies(2) + 1);
>
> What's "plus one"?

I tried to briefly describe it in the comment above with the "in case
we're about to roll over".  ...but more detail...

* I expect HZ to be something like 100.  ...so a jiffy will be 10ms.
2ms will be rounded up to 1 jiffy.

* It's entirely possible that we're about to roll over jiffies.  That
is, we might make the mod_timer call when we're 1 nanosecond away from
moving from 999 to 1000 jiffies.  We'll still read "jiffies" as 999
and add "msecs_to_jiffies(2)" to get 1000 jiffies.  ...but then it
will roll over and we'll make the call mod_timer(1000) when jiffies is
already 1000.  That means that we really got a 1ns delay--not so good.

...if we add the extra 1 jiffy then we'll probably really delay for
10-20ms, but that should be fine in this case.


If I misunderstood the above, please correct me.

>> +     }
>> +
>>       if (mrq->stop)
>>               host->stop_cmdr = dw_mci_prepare_command(slot->mmc, mrq->stop);
>>       else
>> @@ -2158,6 +2167,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
>>               /* Check volt switch first, since it can look like an error */
>>               if ((host->state == STATE_SENDING_CMD11) &&
>>                   (pending & SDMMC_INT_VOLT_SWITCH)) {
>> +                     del_timer(&host->cmd11_timer);
>> +
>>                       mci_writel(host, RINTSTS, SDMMC_INT_VOLT_SWITCH);
>>                       pending &= ~SDMMC_INT_VOLT_SWITCH;
>>                       dw_mci_cmd_interrupt(host, pending);
>> @@ -2571,6 +2582,18 @@ ciu_out:
>>       return ret;
>>  }
>>
>> +static void dw_mci_cmd11_timer(unsigned long arg)
>> +{
>> +     struct dw_mci *host = (struct dw_mci *)arg;
>> +
>> +     if (host->state != STATE_SENDING_CMD11)
>> +             dev_info(host->dev, "Unexpected CMD11 timeout\n");
>
> If Unexpected CMD11 timeout, can it do  just" return"?
> Well, I think Unexpected CMD11 timeout is an rare case.

Duh, of course.  I'm happy to respin this or I'm happy if you want to
just add a "return;"  Please let me know.

-Doug

WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: dw_mmc: Add a timeout for sending CMD11
Date: Fri, 13 Mar 2015 13:38:17 -0700	[thread overview]
Message-ID: <CAD=FV=VcaW3eG49ASWxVV4YgUjiex77Z4ShJV0RJLYh2FEPMsw@mail.gmail.com> (raw)
In-Reply-To: <5502C7CB.3010504@samsung.com>

Jaehoon,

On Fri, Mar 13, 2015 at 4:19 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> Hi Doug.
>
> This patch is a right process. Just i wonder something.
>
> On 03/10/2015 08:18 AM, Doug Anderson wrote:
>> In the Designware databook's description of the "Voltage Switch Normal
>> Scenario" it instructs us to set a timer and fail the voltage change
>> if we don't see the voltage change interrupt within 2ms.  Let's
>> implement that.  Without implementing this I have often been able to
>> reproduce a hang while trying to send CMD11 on an rk3288-based board
>> while constantly ejecting and inserting UHS cards.
>>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> ---
>>  drivers/mmc/host/dw_mmc.c  | 26 ++++++++++++++++++++++++++
>>  include/linux/mmc/dw_mmc.h |  2 ++
>>  2 files changed, 28 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 47dfd0e..d259662 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1020,6 +1020,15 @@ static void __dw_mci_start_request(struct dw_mci *host,
>>
>>       dw_mci_start_command(host, cmd, cmdflags);
>>
>> +     if (cmd->opcode == SD_SWITCH_VOLTAGE) {
>> +             /*
>> +              * Databook says to fail after 2ms w/ no response; give an
>> +              * extra jiffy just in case we're about to roll over.
>> +              */
>> +             mod_timer(&host->cmd11_timer,
>> +                       jiffies + msecs_to_jiffies(2) + 1);
>
> What's "plus one"?

I tried to briefly describe it in the comment above with the "in case
we're about to roll over".  ...but more detail...

* I expect HZ to be something like 100.  ...so a jiffy will be 10ms.
2ms will be rounded up to 1 jiffy.

* It's entirely possible that we're about to roll over jiffies.  That
is, we might make the mod_timer call when we're 1 nanosecond away from
moving from 999 to 1000 jiffies.  We'll still read "jiffies" as 999
and add "msecs_to_jiffies(2)" to get 1000 jiffies.  ...but then it
will roll over and we'll make the call mod_timer(1000) when jiffies is
already 1000.  That means that we really got a 1ns delay--not so good.

...if we add the extra 1 jiffy then we'll probably really delay for
10-20ms, but that should be fine in this case.


If I misunderstood the above, please correct me.

>> +     }
>> +
>>       if (mrq->stop)
>>               host->stop_cmdr = dw_mci_prepare_command(slot->mmc, mrq->stop);
>>       else
>> @@ -2158,6 +2167,8 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
>>               /* Check volt switch first, since it can look like an error */
>>               if ((host->state == STATE_SENDING_CMD11) &&
>>                   (pending & SDMMC_INT_VOLT_SWITCH)) {
>> +                     del_timer(&host->cmd11_timer);
>> +
>>                       mci_writel(host, RINTSTS, SDMMC_INT_VOLT_SWITCH);
>>                       pending &= ~SDMMC_INT_VOLT_SWITCH;
>>                       dw_mci_cmd_interrupt(host, pending);
>> @@ -2571,6 +2582,18 @@ ciu_out:
>>       return ret;
>>  }
>>
>> +static void dw_mci_cmd11_timer(unsigned long arg)
>> +{
>> +     struct dw_mci *host = (struct dw_mci *)arg;
>> +
>> +     if (host->state != STATE_SENDING_CMD11)
>> +             dev_info(host->dev, "Unexpected CMD11 timeout\n");
>
> If Unexpected CMD11 timeout, can it do  just" return"?
> Well, I think Unexpected CMD11 timeout is an rare case.

Duh, of course.  I'm happy to respin this or I'm happy if you want to
just add a "return;"  Please let me know.

-Doug

  reply	other threads:[~2015-03-13 20:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 23:18 [PATCH] mmc: dw_mmc: Add a timeout for sending CMD11 Doug Anderson
2015-03-09 23:18 ` Doug Anderson
2015-03-13 11:19 ` Jaehoon Chung
2015-03-13 11:19   ` Jaehoon Chung
2015-03-13 20:38   ` Doug Anderson [this message]
2015-03-13 20:38     ` Doug Anderson
2015-03-13 20:38     ` Doug Anderson

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='CAD=FV=VcaW3eG49ASWxVV4YgUjiex77Z4ShJV0RJLYh2FEPMsw@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=abrestic@chromium.org \
    --cc=addy.ke@rock-chips.com \
    --cc=alim.akhtar@samsung.com \
    --cc=amstan@chromium.org \
    --cc=chris@printf.net \
    --cc=heiko@sntech.de \
    --cc=javier.martinez@collabora.co.uk \
    --cc=jh80.chung@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=sonnyrao@chromium.org \
    --cc=tgih.jun@samsung.com \
    --cc=ulf.hansson@linaro.org \
    /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.