All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaehoon Chung <jh80.chung@samsung.com>
To: Doug Anderson <dianders@chromium.org>,
	Jaehoon Chung <jh80.chung@samsung.com>
Cc: Seungwon Jeon <tgih.jun@samsung.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Sonny Rao <sonnyrao@chromium.org>,
	Andrew Bresticker <abrestic@chromium.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Addy Ke <addy.ke@rock-chips.com>,
	Alexandru Stan <amstan@chromium.org>,
	Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] mmc: dw_mmc: Increase cmd11 timeout to 500ms
Date: Tue, 07 Apr 2015 11:00:04 +0900	[thread overview]
Message-ID: <55233A24.1000803@samsung.com> (raw)
In-Reply-To: <CAD=FV=XwC8Pc-cA3434XBwXOSPk1MXmCd0Az41afc5-4+==+LA@mail.gmail.com>

Hi, Doug.

On 04/07/2015 04:32 AM, Doug Anderson wrote:
> Jaehoon,
> 
> On Mon, Apr 6, 2015 at 3:46 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> Hi, Doug.
>>
>> On 04/04/2015 03:13 AM, Doug Anderson wrote:
>>> The Designware databook claims that cmd11 should be finished in 2ms,
>>> but my testing showed that not to be the case in some situations.
>>> I've seen cmd11 timeouts of up to 130ms (!) during reboot tests.
>>> Let's bump the timeout way up so that we're absolutely sure.  CMD11 is
>>> only sent during card insertion, so this extra timeout shouldn't be
>>> terrible.
>>
>> Is it h/w problem? Could you explain to me about "some situations"?
>> As you said, this timeout only used during card inserting. So, it's not critical..
>> But there is much different between 2ms and 500ms(or 130ms).
> 
> Very good question, and it makes sense to dig into this...
> 
> OK, I think I've got it.  Dang printk bites me again.  I have serial
> console enabled and my printouts were actually causing these delays.
> With serial console turned off I reliably get ~280us for the interrupt
> to fire (tested across SD and WiFi across 137 + 128 + 111 + 127 = 503
> reboots)

Oh..agreed. I also think printouts can be caused the delay.
Thanks for your explanation.

> 
> I think it makes sense to land this patch anyway, but with an updated
> description.  I'm happy to repost this or happy if you just want to
> update the description when applying.

To save your time, when applying, i will do the updating description.

Best Regards,
Jaehoon Chung

> 
> ---
> 
> Although the cmd11 interrupt should come within 2ms, that's a very
> short time.  Let's increase the timeout to be really sure that we
> don't get an accidnetal timeout.  One case in particular this is
> useful is if you've got a serial console and printk in just the right
> places.  Under that scenario I've seen delays of up to 130ms before
> the interrupt fired.
> 
> CMD11 is only sent during card insertion, so this extra timeout
> shouldn't be terrible.
> 
> ---
> 
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


      reply	other threads:[~2015-04-07  2:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-03 18:13 [PATCH 1/3] mmc: dw_mmc: Increase cmd11 timeout to 500ms Doug Anderson
2015-04-03 18:13 ` [PATCH 2/3] mmc: dw_mmc: Add a return in an unexpected cmd11 timeout Doug Anderson
2015-04-03 18:13 ` [PATCH 3/3] mmc: dw_mmc: Add locking around cmd11 timer Doug Anderson
2015-04-06 10:46 ` [PATCH 1/3] mmc: dw_mmc: Increase cmd11 timeout to 500ms Jaehoon Chung
2015-04-06 19:32   ` Doug Anderson
2015-04-07  2:00     ` Jaehoon Chung [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=55233A24.1000803@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=abrestic@chromium.org \
    --cc=addy.ke@rock-chips.com \
    --cc=alim.akhtar@samsung.com \
    --cc=amstan@chromium.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=javier.martinez@collabora.co.uk \
    --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.