All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds
Date: Tue, 1 Sep 2015 17:35:57 +0200	[thread overview]
Message-ID: <201509011735.57154.marex@denx.de> (raw)
In-Reply-To: <20150901172500.00634a8f@amdc2363>

On Tuesday, September 01, 2015 at 05:25:00 PM, Lukasz Majewski wrote:
> Hi Marek,
> 
> > On Tuesday, September 01, 2015 at 01:19:09 PM, Lukasz Majewski wrote:
> > > Hi Marek,
> > 
> > Hi!
> > 
> > > > On Saturday, August 29, 2015 at 06:38:48 PM, Lukasz Majewski
> > > > 
> > > > wrote:
> > > > > Hi Marek,
> > > > 
> > > > Hi Lukasz,
> > > > 
> > > > > > On Saturday, August 29, 2015 at 01:55:36 PM, Lukasz Majewski
> > > > > > 
> > > > > > wrote:
> > > > > > > On Fri, 28 Aug 2015 23:55:17 +0200
> > > > > > 
> > > > > > Hi!
> > > > > > 
> > > > > > > Marek Vasut <marex@denx.de> wrote:
> > > > > > > > On Friday, August 28, 2015 at 03:50:20 PM, Lukasz Majewski
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > The commit: d9dbb97be0e4a550457aec5f11afefb446169c90
> > > > > > > > > "mmc: dw_mmc: Zap endless timeout" removed endless loop
> > > > > > > > > waiting for end of dw mmc transfer.
> > > > > > > > > 
> > > > > > > > > For some workloads - dfu test @ Odroid XU3 (sending 8MiB
> > > > > > > > > file) - and SD cards (e.g. MicroSD Kingston 4GiB, Adata
> > > > > > > > > 4GiB) the default timeout is to short.
> > > > > > > > > 
> > > > > > > > > The new value - 20 seconds - takes into account the
> > > > > > > > > situation when SD card triggers internal clean up. Such
> > > > > > > > > process may take more than 10 seconds on some cards.
> > > > > > > > 
> > > > > > > > What happens if you pull the SD card out of the slot
> > > > > > > > during such a process?
> > > > > > > 
> > > > > > > Then we would wait 20 seconds :-) to proceed.
> > > > > > 
> > > > > > Oops, I think I was not clear here. I was wondering what
> > > > > > happens to the card if you yank it out of the slot whole it's
> > > > > > performing it's internal cleanup or whatever. Is it possible
> > > > > > that the card suffers data corruption, effectively trashing
> > > > > > user data ?
> > > > > 
> > > > > I think that only the card manufacturer may reveal what can
> > > > > happen with the card (what policy have been implemented in
> > > > > their FW).
> > > > > 
> > > > > I guess that you may lost data in such case.
> > > > 
> > > > Uuuurgh, that's seriously shitty.
> > > > 
> > > > > > Is this behavior
> > > > > > specific to Samsung SD cards ?
> > > > > 
> > > > > I've experienced the problem with Kingston (brand new one) and
> > > > > Adata MicroSD HC (4GiB) cards.
> > > > 
> > > > I had bad previous experience with Kingston too.
> > > > 
> > > > > > > To be clear - the mentioned patch introduced regression.
> > > > > > 
> > > > > > That's a bug, not a regression, but anyway,
> > > > > > that's not the point. I do
> > > > > > agree with you that we do have a problem and I'm inclined to
> > > > > > Ack this patch, I'd like to understand what the real
> > > > > > implications of such a behavior of these cards are.
> > > > > > 
> > > > > > > It works for
> > > > > > > small files on a commonly available SD cards (like 4 GiB
> > > > > > > Kingston/Adata).
> > > > > > > 
> > > > > > > When I ran DFU tests I've discovered that there is a problem
> > > > > > > with storing 8MiB file (dat_8M.img).
> > > > > > > 
> > > > > > > Even worse - when one wants to store Image.itb file (which
> > > > > > > might be 4-6 MiB) it sometimes works and sometimes not.
> > > > > > > Nightmare for debugging.
> > > > > > 
> > > > > > Ew, that's one crappy card you have there. I'm reading the SD
> > > > > > card "Physical Layer Simplified Specification Version
> > > > > > 4.10" (part1_410.pdf) section 4.6.2.2 and it states that for
> > > > > > SDHC cards, the write operation should take at most 250mS,
> > > > > > for SDXC it's 500mS. Could it be that your card is violating
> > > > > > the spec ?
> > > 
> > > The "timeout" error is for situation when you issue write command
> > > (either single or multiple block) and you don't receive any response
> > > from the card.
> > > 
> > > In our case we use multiblock transfer (CMD25) with either set
> > > number of block to transfer (CMD23) or explicit end of transmission
> > > (CMD12).
> > > 
> > > Let's consider the second case.
> > > 
> > > We setup data and issue CMD25. Then we check the CMD25 status (if we
> > > don't receive reply in 250 ms we would get timeout error).
> > > Afterwards data from buffer is transmitted to the card and flashed.
> > > This operation may take long time. During this process you can issue
> > > CMD13 (SEND_STATUS) to receive information about card state ([*]
> > > 4.10. - page 85).
> > 
> > Maybe we should implement such polling through CMD13 then ? But, this
> > should be a matter for next MW, this MW we should go with increasing
> > the timeout to some 20 or 30 second. What do you think ?
> 
> For next release we can increase the timeout. Rewritting eMMC subsystem
> code is a challenging task and we will not finish until the next u-boot
> release.

Yeah, we're in agreement.

  reply	other threads:[~2015-09-01 15:35 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 13:50 [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds Lukasz Majewski
2015-08-28 13:50 ` [U-Boot] [PATCH 2/2] mmc: dw_mmc: Make timeout error visible to u-boot console Lukasz Majewski
2015-08-28 23:21   ` Simon Glass
2015-08-29 12:09     ` Lukasz Majewski
2015-08-29 15:07       ` Simon Glass
2015-09-03 12:33         ` Lukasz Majewski
2015-09-03 12:21   ` [U-Boot] [PATCH] FIX: fat: Provide correct return code from disk_{read|write} to upper layers Lukasz Majewski
2015-09-03 12:44     ` Tom Rini
2015-09-03 13:40       ` Lukasz Majewski
2015-09-03 14:18         ` Lukasz Majewski
2015-09-23  3:17           ` Stephen Warren
2015-09-23  8:40             ` Lukasz Majewski
2015-09-25  5:47               ` Stephen Warren
2015-09-09  7:02     ` Lukasz Majewski
2015-09-17 14:44       ` Lukasz Majewski
2015-09-12 12:51     ` [U-Boot] " Tom Rini
2015-08-28 21:55 ` [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds Marek Vasut
2015-08-29 11:55   ` Lukasz Majewski
2015-08-29 13:52     ` Marek Vasut
2015-08-29 16:38       ` Lukasz Majewski
2015-08-29 19:19         ` Marek Vasut
2015-09-01 11:19           ` Lukasz Majewski
2015-09-01 11:33             ` Marek Vasut
2015-09-01 15:25               ` Lukasz Majewski
2015-09-01 15:35                 ` Marek Vasut [this message]
2015-09-01 16:22           ` Pantelis Antoniou
2015-09-02  8:06             ` Marek Vasut
2015-09-09  7:01 ` Lukasz Majewski
2015-09-09 11:34   ` Marek Vasut
2015-09-11 17:20     ` Alexey Brodkin
2015-09-11 21:45       ` Lukasz Majewski
2015-09-12 16:13         ` Marek Vasut
2015-09-13 10:03           ` Lukasz Majewski
2015-09-13 14:00             ` Marek Vasut
2015-09-14 10:15               ` Alexey Brodkin
2015-09-14 11:22                 ` Lukasz Majewski
2015-09-14 13:36                   ` Marek Vasut
2015-09-17 14:43                     ` Lukasz Majewski
2015-09-18  0:31                       ` Tom Rini
2015-09-18  7:32                         ` Lukasz Majewski
2015-09-18  8:07                           ` Przemyslaw Marczak
2015-09-18 19:27                           ` Tom Rini
2015-09-21 15:32                             ` Pantelis Antoniou
2015-09-14 10:30         ` Alexey Brodkin
2015-09-14 11:15           ` Przemyslaw Marczak
2015-09-14 10:33   ` Przemyslaw Marczak
2015-09-25 16:25 ` [U-Boot] [PATCH] mmc: dw_mmc: Increase timeout to 4 minutes (as in Linux kernel) Lukasz Majewski
2015-09-28 13:43   ` Przemyslaw Marczak
2015-09-28 21:08     ` Tom Rini
2015-09-28 21:08   ` [U-Boot] " Tom Rini

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=201509011735.57154.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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.