* [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
@ 2012-03-01 17:26 Chase Maupin
2012-03-06 12:54 ` Maupin, Chase
2012-03-09 4:38 ` Chris Ball
0 siblings, 2 replies; 16+ messages in thread
From: Chase Maupin @ 2012-03-01 17:26 UTC (permalink / raw)
To: linux-omap, linux-mmc; +Cc: Chase Maupin
* With certain SD cards timeouts like the following have been seen
due to an improper calculation of the dto value:
mmcblk0: error -110 transferring data, sector 4126233, nr 8,
card status 0xc00
* By removing the dto calculation and setting the timeout value
to the maximum specified by the SD card specification part A2
section 2.2.15 these timeouts can be avoided.
* This change has been used by beagleboard users as well as the
Texas Instruments SDK without a negative impact.
* There are multiple discussion threads about this but the most
relevant ones are:
* http://talk.maemo.org/showthread.php?p=1000707#post1000707
* http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
* Original proposal for this fix was done by Sukumar Ghoral of
Texas Instruments
* Tested using a Texas Instruments AM335x EVM
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
---
drivers/mmc/host/omap_hsmmc.c | 30 +++++-------------------------
1 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..afd7292 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1481,11 +1481,8 @@ static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
return 0;
}
-static void set_data_timeout(struct omap_hsmmc_host *host,
- unsigned int timeout_ns,
- unsigned int timeout_clks)
+static void set_data_timeout(struct omap_hsmmc_host *host)
{
- unsigned int timeout, cycle_ns;
uint32_t reg, clkd, dto = 0;
reg = OMAP_HSMMC_READ(host->base, SYSCTL);
@@ -1493,25 +1490,8 @@ static void set_data_timeout(struct omap_hsmmc_host *host,
if (clkd == 0)
clkd = 1;
- cycle_ns = 1000000000 / (clk_get_rate(host->fclk) / clkd);
- timeout = timeout_ns / cycle_ns;
- timeout += timeout_clks;
- if (timeout) {
- while ((timeout & 0x80000000) == 0) {
- dto += 1;
- timeout <<= 1;
- }
- dto = 31 - dto;
- timeout <<= 1;
- if (timeout && dto)
- dto += 1;
- if (dto >= 13)
- dto -= 13;
- else
- dto = 0;
- if (dto > 14)
- dto = 14;
- }
+ /* Use the maximum timeout value allowed in the standard of 14 or 0xE */
+ dto = 14;
reg &= ~DTO_MASK;
reg |= dto << DTO_SHIFT;
@@ -1534,13 +1514,13 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host, struct mmc_request *req)
* busy signal.
*/
if (req->cmd->flags & MMC_RSP_BUSY)
- set_data_timeout(host, 100000000U, 0);
+ set_data_timeout(host);
return 0;
}
OMAP_HSMMC_WRITE(host->base, BLK, (req->data->blksz)
| (req->data->blocks << 16));
- set_data_timeout(host, req->data->timeout_ns, req->data->timeout_clks);
+ set_data_timeout(host);
if (host->use_dma) {
ret = omap_hsmmc_start_dma_transfer(host, req);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-01 17:26 [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices Chase Maupin
@ 2012-03-06 12:54 ` Maupin, Chase
2012-03-09 4:38 ` Chris Ball
1 sibling, 0 replies; 16+ messages in thread
From: Maupin, Chase @ 2012-03-06 12:54 UTC (permalink / raw)
To: Maupin, Chase, linux-omap, linux-mmc
Ping on this patch. I have not seen any response on the list but if I have missed something please let me know.
> -----Original Message-----
> From: Maupin, Chase
> Sent: Thursday, March 01, 2012 11:26 AM
> To: linux-omap@vger.kernel.org; linux-mmc@vger.kernel.org
> Cc: Maupin, Chase
> Subject: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
>
> * With certain SD cards timeouts like the following have been seen
> due to an improper calculation of the dto value:
> mmcblk0: error -110 transferring data, sector 4126233, nr 8,
> card status 0xc00
> * By removing the dto calculation and setting the timeout value
> to the maximum specified by the SD card specification part A2
> section 2.2.15 these timeouts can be avoided.
> * This change has been used by beagleboard users as well as the
> Texas Instruments SDK without a negative impact.
> * There are multiple discussion threads about this but the most
> relevant ones are:
> * http://talk.maemo.org/showthread.php?p=1000707#post1000707
> * http://www.mail-archive.com/linux-
> omap@vger.kernel.org/msg42213.html
> * Original proposal for this fix was done by Sukumar Ghoral of
> Texas Instruments
>
> * Tested using a Texas Instruments AM335x EVM
>
> Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
> ---
> drivers/mmc/host/omap_hsmmc.c | 30 +++++------------------------
> -
> 1 files changed, 5 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c
> index fd0c661..afd7292 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1481,11 +1481,8 @@ static int
> omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
> return 0;
> }
>
> -static void set_data_timeout(struct omap_hsmmc_host *host,
> - unsigned int timeout_ns,
> - unsigned int timeout_clks)
> +static void set_data_timeout(struct omap_hsmmc_host *host)
> {
> - unsigned int timeout, cycle_ns;
> uint32_t reg, clkd, dto = 0;
>
> reg = OMAP_HSMMC_READ(host->base, SYSCTL);
> @@ -1493,25 +1490,8 @@ static void set_data_timeout(struct
> omap_hsmmc_host *host,
> if (clkd == 0)
> clkd = 1;
>
> - cycle_ns = 1000000000 / (clk_get_rate(host->fclk) / clkd);
> - timeout = timeout_ns / cycle_ns;
> - timeout += timeout_clks;
> - if (timeout) {
> - while ((timeout & 0x80000000) == 0) {
> - dto += 1;
> - timeout <<= 1;
> - }
> - dto = 31 - dto;
> - timeout <<= 1;
> - if (timeout && dto)
> - dto += 1;
> - if (dto >= 13)
> - dto -= 13;
> - else
> - dto = 0;
> - if (dto > 14)
> - dto = 14;
> - }
> + /* Use the maximum timeout value allowed in the standard of 14
> or 0xE */
> + dto = 14;
>
> reg &= ~DTO_MASK;
> reg |= dto << DTO_SHIFT;
> @@ -1534,13 +1514,13 @@ omap_hsmmc_prepare_data(struct
> omap_hsmmc_host *host, struct mmc_request *req)
> * busy signal.
> */
> if (req->cmd->flags & MMC_RSP_BUSY)
> - set_data_timeout(host, 100000000U, 0);
> + set_data_timeout(host);
> return 0;
> }
>
> OMAP_HSMMC_WRITE(host->base, BLK, (req->data->blksz)
> | (req->data->blocks << 16));
> - set_data_timeout(host, req->data->timeout_ns, req->data-
> >timeout_clks);
> + set_data_timeout(host);
>
> if (host->use_dma) {
> ret = omap_hsmmc_start_dma_transfer(host, req);
> --
> 1.7.0.4
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-01 17:26 [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices Chase Maupin
2012-03-06 12:54 ` Maupin, Chase
@ 2012-03-09 4:38 ` Chris Ball
2012-03-09 13:06 ` Maupin, Chase
2012-03-12 10:58 ` Paul Walmsley
1 sibling, 2 replies; 16+ messages in thread
From: Chris Ball @ 2012-03-09 4:38 UTC (permalink / raw)
To: Chase Maupin; +Cc: linux-omap, linux-mmc
Hi Chase,
On Thu, Mar 01 2012, Chase Maupin wrote:
> * With certain SD cards timeouts like the following have been seen
> due to an improper calculation of the dto value:
> mmcblk0: error -110 transferring data, sector 4126233, nr 8,
> card status 0xc00
> * By removing the dto calculation and setting the timeout value
> to the maximum specified by the SD card specification part A2
> section 2.2.15 these timeouts can be avoided.
> * This change has been used by beagleboard users as well as the
> Texas Instruments SDK without a negative impact.
> * There are multiple discussion threads about this but the most
> relevant ones are:
> * http://talk.maemo.org/showthread.php?p=1000707#post1000707
> * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
> * Original proposal for this fix was done by Sukumar Ghoral of
> Texas Instruments
>
> * Tested using a Texas Instruments AM335x EVM
>
> Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
Thanks, I've pushed this to mmc-next for 3.4. (With a trivial
indentation fix, below.)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82b400793..9d4ce1c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1360,7 +1360,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host)
if (clkd == 0)
clkd = 1;
- /* Use the maximum timeout value allowed in the standard of 14 or 0xE */
+ /* Use the maximum timeout value allowed in the standard of 14 or 0xE */
dto = 14;
reg &= ~DTO_MASK;
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-09 4:38 ` Chris Ball
@ 2012-03-09 13:06 ` Maupin, Chase
2012-03-12 10:58 ` Paul Walmsley
1 sibling, 0 replies; 16+ messages in thread
From: Maupin, Chase @ 2012-03-09 13:06 UTC (permalink / raw)
To: Chris Ball; +Cc: linux-omap, linux-mmc
> -----Original Message-----
> From: Chris Ball [mailto:cjb@laptop.org]
> Sent: Thursday, March 08, 2012 10:39 PM
> To: Maupin, Chase
> Cc: linux-omap@vger.kernel.org; linux-mmc@vger.kernel.org
> Subject: Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
>
> Hi Chase,
>
> On Thu, Mar 01 2012, Chase Maupin wrote:
> > * With certain SD cards timeouts like the following have been
> seen
> > due to an improper calculation of the dto value:
> > mmcblk0: error -110 transferring data, sector 4126233, nr 8,
> > card status 0xc00
> > * By removing the dto calculation and setting the timeout value
> > to the maximum specified by the SD card specification part A2
> > section 2.2.15 these timeouts can be avoided.
> > * This change has been used by beagleboard users as well as the
> > Texas Instruments SDK without a negative impact.
> > * There are multiple discussion threads about this but the most
> > relevant ones are:
> > * http://talk.maemo.org/showthread.php?p=1000707#post1000707
> > * http://www.mail-archive.com/linux-
> omap@vger.kernel.org/msg42213.html
> > * Original proposal for this fix was done by Sukumar Ghoral of
> > Texas Instruments
> >
> > * Tested using a Texas Instruments AM335x EVM
> >
> > Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
>
> Thanks, I've pushed this to mmc-next for 3.4. (With a trivial
> indentation fix, below.)
Thank you Chris.
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c
> index 82b400793..9d4ce1c 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1360,7 +1360,7 @@ static void set_data_timeout(struct
> omap_hsmmc_host *host)
> if (clkd == 0)
> clkd = 1;
>
> - /* Use the maximum timeout value allowed in the standard of 14
> or 0xE */
> + /* Use the maximum timeout value allowed in the standard of
> 14 or 0xE */
> dto = 14;
>
> reg &= ~DTO_MASK;
>
>
> - Chris.
> --
> Chris Ball <cjb@laptop.org> <http://printf.net/>
> One Laptop Per Child
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-09 4:38 ` Chris Ball
2012-03-09 13:06 ` Maupin, Chase
@ 2012-03-12 10:58 ` Paul Walmsley
2012-03-12 11:10 ` Paul Walmsley
` (2 more replies)
1 sibling, 3 replies; 16+ messages in thread
From: Paul Walmsley @ 2012-03-12 10:58 UTC (permalink / raw)
To: Chris Ball; +Cc: Chase Maupin, linux-omap, linux-mmc, sakoman
+ Steve Sakoman
Hi Chris, Chase,
Sorry for the late comment on this; I just noticed this thread.
On Thu, 8 Mar 2012, Chris Ball wrote:
> On Thu, Mar 01 2012, Chase Maupin wrote:
> > * With certain SD cards timeouts like the following have been seen
> > due to an improper calculation of the dto value:
> > mmcblk0: error -110 transferring data, sector 4126233, nr 8,
> > card status 0xc00
> > * By removing the dto calculation and setting the timeout value
> > to the maximum specified by the SD card specification part A2
> > section 2.2.15 these timeouts can be avoided.
> > * This change has been used by beagleboard users as well as the
> > Texas Instruments SDK without a negative impact.
> > * There are multiple discussion threads about this but the most
> > relevant ones are:
> > * http://talk.maemo.org/showthread.php?p=1000707#post1000707
> > * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
> > * Original proposal for this fix was done by Sukumar Ghoral of
> > Texas Instruments
> >
> > * Tested using a Texas Instruments AM335x EVM
> >
> > Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
>
> Thanks, I've pushed this to mmc-next for 3.4. (With a trivial
> indentation fix, below.)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 82b400793..9d4ce1c 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1360,7 +1360,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host)
> if (clkd == 0)
> clkd = 1;
>
> - /* Use the maximum timeout value allowed in the standard of 14 or 0xE */
> + /* Use the maximum timeout value allowed in the standard of 14 or 0xE */
> dto = 14;
>
> reg &= ~DTO_MASK;
I don't think this is the right fix. Steve Sakoman and I discussed this a
few months ago -- we did some debugging and Steve observed the timeouts on
multiple block writes (0x19):
hsmmc: command 00000019
hsmmc: orig_rate = 96000000, div = 2, dto = 11
hsmmc: using 300000000 ns DTO
hsmmc: command 0000000d
mmcblk0: error -110 transferring data, sector 15257840, nr 96, card status 0xc00
So dto = 11 @ 48MHz is a 350ms timeout ((2^(11+13)) / 48000000).
I don't have an SD bus analyzer, but it looks to me think there are some
SD cards that are not completing the write within the allotted time
window. It should be 250ms according to this SD spec:
https://www.sdcard.org/developers/tech/pls/simplified_specs/Part_1_Physical_Layer_Simplified_Specification_Ver_3.01_Final_100518.pdf
The spec also says "It is strongly recommended for hosts to implement more
than 500ms timeout value even if the card indicates the 250ms maximum busy
length."
So to me, this should probably be solved in the generic Linux MMC layer.
mmc_set_data_timeout() should presumably be using a huge timeout on
writes. Don't know what it should be but the current 300ms goal is
arbitrary anyway - see commit 493890e75d98810a3470b4aae23be628ee5e9667
("mmc: increase SD write timeout for crappy cards").
Otherwise, if we just change the OMAP host controller driver, we could run
into the same problem on other controllers. While this issue could be an
OMAP specific problem, at the moment I don't see any obvious evidence of
that.
So perhaps something like the following patch instead? Unfortunately, I
don't have one of these crappy SD cards as far as I know, so I can't
really test it.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 12 Mar 2012 04:46:29 -0600
Subject: [PATCH] mmc: use really long write timeout to deal with crappy cards
Several people have noticed that crappy SD cards take much longer to
complete multiple block writes than the 300ms that Linux specifies.
Try to work around this by using a three second write timeout instead.
<insert Chase's patch description here>
Not-yet-signed-off-by: Paul Walmsley <paul@pwsan.com>
---
drivers/mmc/core/core.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 690255c..0f2caca 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -526,10 +526,14 @@ void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card)
if (data->flags & MMC_DATA_WRITE)
/*
- * The limit is really 250 ms, but that is
- * insufficient for some crappy cards.
+ * The MMC spec "It is strongly recommended
+ * for hosts to implement more than 500ms
+ * timeout value even if the card indicates
+ * the 250ms maximum busy length." Even the
+ * previous value of 300ms is known to be
+ * insufficient for some cards.
*/
- limit_us = 300000;
+ limit_us = 3000000;
else
limit_us = 100000;
--
1.7.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-12 10:58 ` Paul Walmsley
@ 2012-03-12 11:10 ` Paul Walmsley
2012-03-12 14:37 ` Maupin, Chase
2012-03-16 3:22 ` Chris Ball
2 siblings, 0 replies; 16+ messages in thread
From: Paul Walmsley @ 2012-03-12 11:10 UTC (permalink / raw)
To: Chris Ball; +Cc: Chase Maupin, linux-omap, linux-mmc, sakoman
On Mon, 12 Mar 2012, Paul Walmsley wrote:
> I don't have an SD bus analyzer, but it looks to me think there are some
> SD cards that are not completing the write within the allotted time
> window.
Heh, sorry. This should, of course, read "looks to me _that_". Sigh...
- Paul
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-12 10:58 ` Paul Walmsley
2012-03-12 11:10 ` Paul Walmsley
@ 2012-03-12 14:37 ` Maupin, Chase
2012-03-16 3:22 ` Chris Ball
2 siblings, 0 replies; 16+ messages in thread
From: Maupin, Chase @ 2012-03-12 14:37 UTC (permalink / raw)
To: Paul Walmsley, Chris Ball; +Cc: linux-omap, linux-mmc, sakoman
> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Monday, March 12, 2012 5:58 AM
> To: Chris Ball
> Cc: Maupin, Chase; linux-omap@vger.kernel.org; linux-
> mmc@vger.kernel.org; sakoman@gmail.com
> Subject: Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
>
> + Steve Sakoman
>
> Hi Chris, Chase,
>
> Sorry for the late comment on this; I just noticed this thread.
>
> On Thu, 8 Mar 2012, Chris Ball wrote:
>
> > On Thu, Mar 01 2012, Chase Maupin wrote:
> > > * With certain SD cards timeouts like the following have been
> seen
> > > due to an improper calculation of the dto value:
> > > mmcblk0: error -110 transferring data, sector 4126233, nr
> 8,
> > > card status 0xc00
> > > * By removing the dto calculation and setting the timeout value
> > > to the maximum specified by the SD card specification part A2
> > > section 2.2.15 these timeouts can be avoided.
> > > * This change has been used by beagleboard users as well as the
> > > Texas Instruments SDK without a negative impact.
> > > * There are multiple discussion threads about this but the most
> > > relevant ones are:
> > > *
> http://talk.maemo.org/showthread.php?p=1000707#post1000707
> > > * http://www.mail-archive.com/linux-
> omap@vger.kernel.org/msg42213.html
> > > * Original proposal for this fix was done by Sukumar Ghoral of
> > > Texas Instruments
> > >
> > > * Tested using a Texas Instruments AM335x EVM
> > >
> > > Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
> >
> > Thanks, I've pushed this to mmc-next for 3.4. (With a trivial
> > indentation fix, below.)
> >
> > diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c
> > index 82b400793..9d4ce1c 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -1360,7 +1360,7 @@ static void set_data_timeout(struct
> omap_hsmmc_host *host)
> > if (clkd == 0)
> > clkd = 1;
> >
> > - /* Use the maximum timeout value allowed in the standard of
> 14 or 0xE */
> > + /* Use the maximum timeout value allowed in the standard of
> 14 or 0xE */
> > dto = 14;
> >
> > reg &= ~DTO_MASK;
>
> I don't think this is the right fix. Steve Sakoman and I discussed
> this a
> few months ago -- we did some debugging and Steve observed the
> timeouts on
> multiple block writes (0x19):
>
> hsmmc: command 00000019
> hsmmc: orig_rate = 96000000, div = 2, dto = 11
> hsmmc: using 300000000 ns DTO
> hsmmc: command 0000000d
> mmcblk0: error -110 transferring data, sector 15257840, nr 96, card
> status 0xc00
>
> So dto = 11 @ 48MHz is a 350ms timeout ((2^(11+13)) / 48000000).
>
> I don't have an SD bus analyzer, but it looks to me think there are
> some
> SD cards that are not completing the write within the allotted time
> window. It should be 250ms according to this SD spec:
>
> https://www.sdcard.org/developers/tech/pls/simplified_specs/Part_1_
> Physical_Layer_Simplified_Specification_Ver_3.01_Final_100518.pdf
>
> The spec also says "It is strongly recommended for hosts to
> implement more
> than 500ms timeout value even if the card indicates the 250ms
> maximum busy
> length."
>
> So to me, this should probably be solved in the generic Linux MMC
> layer.
> mmc_set_data_timeout() should presumably be using a huge timeout on
> writes. Don't know what it should be but the current 300ms goal is
> arbitrary anyway - see commit
> 493890e75d98810a3470b4aae23be628ee5e9667
> ("mmc: increase SD write timeout for crappy cards").
>
> Otherwise, if we just change the OMAP host controller driver, we
> could run
> into the same problem on other controllers. While this issue could
> be an
> OMAP specific problem, at the moment I don't see any obvious
> evidence of
> that.
>
> So perhaps something like the following patch instead?
> Unfortunately, I
> don't have one of these crappy SD cards as far as I know, so I
> can't
> really test it.
I would be OK with that. I picked the dto=14 because it has worked for us as well as that being the max value I saw defined in section 2 of the spec (section 2.2.15 to be exact). If you want to pull this up to be more generic I think that makes sense.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Mon, 12 Mar 2012 04:46:29 -0600
> Subject: [PATCH] mmc: use really long write timeout to deal with
> crappy cards
>
> Several people have noticed that crappy SD cards take much longer
> to
> complete multiple block writes than the 300ms that Linux specifies.
> Try to work around this by using a three second write timeout
> instead.
>
> <insert Chase's patch description here>
>
> Not-yet-signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
> drivers/mmc/core/core.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 690255c..0f2caca 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -526,10 +526,14 @@ void mmc_set_data_timeout(struct mmc_data
> *data, const struct mmc_card *card)
>
> if (data->flags & MMC_DATA_WRITE)
> /*
> - * The limit is really 250 ms, but that is
> - * insufficient for some crappy cards.
> + * The MMC spec "It is strongly recommended
> + * for hosts to implement more than 500ms
> + * timeout value even if the card indicates
> + * the 250ms maximum busy length." Even the
> + * previous value of 300ms is known to be
> + * insufficient for some cards.
> */
> - limit_us = 300000;
> + limit_us = 3000000;
> else
> limit_us = 100000;
>
> --
> 1.7.9.1
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-12 10:58 ` Paul Walmsley
2012-03-12 11:10 ` Paul Walmsley
2012-03-12 14:37 ` Maupin, Chase
@ 2012-03-16 3:22 ` Chris Ball
2012-04-05 22:08 ` Tony Lindgren
2 siblings, 1 reply; 16+ messages in thread
From: Chris Ball @ 2012-03-16 3:22 UTC (permalink / raw)
To: Paul Walmsley; +Cc: Chase Maupin, linux-omap, linux-mmc, sakoman
Hi Paul,
On Mon, Mar 12 2012, Paul Walmsley wrote:
> I don't think this is the right fix. Steve Sakoman and I discussed this a
> few months ago -- we did some debugging and Steve observed the timeouts on
> multiple block writes (0x19):
> [...]
> So perhaps something like the following patch instead? Unfortunately, I
> don't have one of these crappy SD cards as far as I know, so I can't
> really test it.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Mon, 12 Mar 2012 04:46:29 -0600
> Subject: [PATCH] mmc: use really long write timeout to deal with crappy cards
>
> Several people have noticed that crappy SD cards take much longer to
> complete multiple block writes than the 300ms that Linux specifies.
> Try to work around this by using a three second write timeout instead.
>
> <insert Chase's patch description here>
>
> Not-yet-signed-off-by: Paul Walmsley <paul@pwsan.com>
Sounds like a good idea -- want to send a signed-off patch for this?
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-03-16 3:22 ` Chris Ball
@ 2012-04-05 22:08 ` Tony Lindgren
2012-04-05 22:15 ` Chris Ball
0 siblings, 1 reply; 16+ messages in thread
From: Tony Lindgren @ 2012-04-05 22:08 UTC (permalink / raw)
To: Chris Ball; +Cc: Paul Walmsley, Chase Maupin, linux-omap, linux-mmc, sakoman
* Chris Ball <cjb@laptop.org> [120315 20:26]:
> Hi Paul,
>
> On Mon, Mar 12 2012, Paul Walmsley wrote:
> > I don't think this is the right fix. Steve Sakoman and I discussed this a
> > few months ago -- we did some debugging and Steve observed the timeouts on
> > multiple block writes (0x19):
> > [...]
> > So perhaps something like the following patch instead? Unfortunately, I
> > don't have one of these crappy SD cards as far as I know, so I can't
> > really test it.
> >
> >
> > - Paul
> >
> > From: Paul Walmsley <paul@pwsan.com>
> > Date: Mon, 12 Mar 2012 04:46:29 -0600
> > Subject: [PATCH] mmc: use really long write timeout to deal with crappy cards
> >
> > Several people have noticed that crappy SD cards take much longer to
> > complete multiple block writes than the 300ms that Linux specifies.
> > Try to work around this by using a three second write timeout instead.
> >
> > <insert Chase's patch description here>
> >
> > Not-yet-signed-off-by: Paul Walmsley <paul@pwsan.com>
>
> Sounds like a good idea -- want to send a signed-off patch for this?
This seems like the right fix to me too. Works on my pandaboard es and
some random card that produces I/O errors without this.
Tested-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-05 22:08 ` Tony Lindgren
@ 2012-04-05 22:15 ` Chris Ball
2012-04-05 23:44 ` Paul Walmsley
0 siblings, 1 reply; 16+ messages in thread
From: Chris Ball @ 2012-04-05 22:15 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Paul Walmsley, Chase Maupin, linux-omap, linux-mmc, sakoman
Hi,
On Thu, Apr 05 2012, Tony Lindgren wrote:
> * Chris Ball <cjb@laptop.org> [120315 20:26]:
>> Hi Paul,
>>
>> On Mon, Mar 12 2012, Paul Walmsley wrote:
>> > I don't think this is the right fix. Steve Sakoman and I discussed this a
>> > few months ago -- we did some debugging and Steve observed the timeouts on
>> > multiple block writes (0x19):
>> > [...]
>> > So perhaps something like the following patch instead? Unfortunately, I
>> > don't have one of these crappy SD cards as far as I know, so I can't
>> > really test it.
>> >
>> >
>> > - Paul
>> >
>> > From: Paul Walmsley <paul@pwsan.com>
>> > Date: Mon, 12 Mar 2012 04:46:29 -0600
>> > Subject: [PATCH] mmc: use really long write timeout to deal with crappy cards
>> >
>> > Several people have noticed that crappy SD cards take much longer to
>> > complete multiple block writes than the 300ms that Linux specifies.
>> > Try to work around this by using a three second write timeout instead.
>> >
>> > <insert Chase's patch description here>
>> >
>> > Not-yet-signed-off-by: Paul Walmsley <paul@pwsan.com>
>>
>> Sounds like a good idea -- want to send a signed-off patch for this?
>
> This seems like the right fix to me too. Works on my pandaboard es and
> some random card that produces I/O errors without this.
>
> Tested-by: Tony Lindgren <tony@atomide.com>
Thanks. Paul, just waiting for your Signed-off-by.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-05 22:15 ` Chris Ball
@ 2012-04-05 23:44 ` Paul Walmsley
2012-04-05 23:54 ` Chris Ball
0 siblings, 1 reply; 16+ messages in thread
From: Paul Walmsley @ 2012-04-05 23:44 UTC (permalink / raw)
To: Chris Ball; +Cc: Tony Lindgren, Chase Maupin, linux-omap, linux-mmc, sakoman
Hi Chris,
I'm really sorry for the long delay!
On Thu, 5 Apr 2012, Chris Ball wrote:
> Thanks. Paul, just waiting for your Signed-off-by.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-05 23:44 ` Paul Walmsley
@ 2012-04-05 23:54 ` Chris Ball
2012-04-12 9:46 ` Tushar Behera
0 siblings, 1 reply; 16+ messages in thread
From: Chris Ball @ 2012-04-05 23:54 UTC (permalink / raw)
To: Paul Walmsley; +Cc: Tony Lindgren, Chase Maupin, linux-omap, linux-mmc, sakoman
Hi Paul,
On Thu, Apr 05 2012, Paul Walmsley wrote:
> I'm really sorry for the long delay!
>
> On Thu, 5 Apr 2012, Chris Ball wrote:
>
>> Thanks. Paul, just waiting for your Signed-off-by.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thanks, no problem! Pushed to mmc-next for 3.4.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-05 23:54 ` Chris Ball
@ 2012-04-12 9:46 ` Tushar Behera
2012-04-12 17:56 ` Paul Walmsley
0 siblings, 1 reply; 16+ messages in thread
From: Tushar Behera @ 2012-04-12 9:46 UTC (permalink / raw)
To: Chris Ball
Cc: Paul Walmsley, Tony Lindgren, Chase Maupin, linux-omap,
linux-mmc, sakoman
On 04/06/2012 05:24 AM, Chris Ball wrote:
> Hi Paul,
>
> On Thu, Apr 05 2012, Paul Walmsley wrote:
>> I'm really sorry for the long delay!
>>
>> On Thu, 5 Apr 2012, Chris Ball wrote:
>>
>>> Thanks. Paul, just waiting for your Signed-off-by.
>>
>> Signed-off-by: Paul Walmsley <paul@pwsan.com>
>
> Thanks, no problem! Pushed to mmc-next for 3.4.
>
> - Chris.
With this patch, I continuously get following message on my console.
(Tested on Origen board, based on EXYNOS4210).
mmc0: Too large timeout requested for CMD25!
So, with this change, should we update sdhci_calc_timeout() also?
--
Tushar Behera
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-12 9:46 ` Tushar Behera
@ 2012-04-12 17:56 ` Paul Walmsley
2012-04-12 18:19 ` Chris Ball
0 siblings, 1 reply; 16+ messages in thread
From: Paul Walmsley @ 2012-04-12 17:56 UTC (permalink / raw)
To: Tushar Behera
Cc: Chris Ball, Tony Lindgren, Chase Maupin, linux-omap, linux-mmc, sakoman
Hello Tushar,
On Thu, 12 Apr 2012, Tushar Behera wrote:
> With this patch, I continuously get following message on my console.
> (Tested on Origen board, based on EXYNOS4210).
>
> mmc0: Too large timeout requested for CMD25!
>
> So, with this change, should we update sdhci_calc_timeout() also?
Looks like most of the host drivers that range-check the timeout value
silently clamp it at the hardware-supported maximum value:
drivers/mmc/host/atmel-mci.c
drivers/mmc/host/davinci_mmc.c
drivers/mmc/host/mvsdio.c
drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/wbsd.c
drivers/mmc/host/tifm_sd.c
So maybe try the same thing for your driver?
Of course it seems that some drivers don't range-check the timeout value
at all :-(
drivers/mmc/host/bfin_sdh.c
drivers/mmc/host/mmci.c
drivers/mmc/host/msm_sdcc.c
drivers/mmc/host/pxamci.c
drivers/mmc/host/mxs-mmc.c
drivers/mmc/host/omap.c
- Paul
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-12 17:56 ` Paul Walmsley
@ 2012-04-12 18:19 ` Chris Ball
2012-04-14 9:38 ` Paul Walmsley
0 siblings, 1 reply; 16+ messages in thread
From: Chris Ball @ 2012-04-12 18:19 UTC (permalink / raw)
To: Paul Walmsley
Cc: Tushar Behera, Tony Lindgren, Chase Maupin, linux-omap,
linux-mmc, sakoman
Hi,
On Thu, Apr 12 2012, Paul Walmsley wrote:
>> With this patch, I continuously get following message on my console.
>> (Tested on Origen board, based on EXYNOS4210).
>>
>> mmc0: Too large timeout requested for CMD25!
>>
>> So, with this change, should we update sdhci_calc_timeout() also?
>
> Looks like most of the host drivers that range-check the timeout value
> silently clamp it at the hardware-supported maximum value:
If I understand correctly, the only problem here is the presence of the
warning, so I'm leaning towards just removing it (which we've already
had another request for) or making it pr_debug() instead. Sound okay?
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
2012-04-12 18:19 ` Chris Ball
@ 2012-04-14 9:38 ` Paul Walmsley
0 siblings, 0 replies; 16+ messages in thread
From: Paul Walmsley @ 2012-04-14 9:38 UTC (permalink / raw)
To: Chris Ball
Cc: Tushar Behera, Tony Lindgren, Chase Maupin, linux-omap,
linux-mmc, sakoman
Hi Chris,
On Thu, 12 Apr 2012, Chris Ball wrote:
> If I understand correctly, the only problem here is the presence of the
> warning, so I'm leaning towards just removing it (which we've already
> had another request for) or making it pr_debug() instead. Sound okay?
Sounds okay to me.
We'll probably also need to take a look at the drivers that don't
range-check their timeouts.
- Paul
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-04-14 9:38 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-01 17:26 [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices Chase Maupin
2012-03-06 12:54 ` Maupin, Chase
2012-03-09 4:38 ` Chris Ball
2012-03-09 13:06 ` Maupin, Chase
2012-03-12 10:58 ` Paul Walmsley
2012-03-12 11:10 ` Paul Walmsley
2012-03-12 14:37 ` Maupin, Chase
2012-03-16 3:22 ` Chris Ball
2012-04-05 22:08 ` Tony Lindgren
2012-04-05 22:15 ` Chris Ball
2012-04-05 23:44 ` Paul Walmsley
2012-04-05 23:54 ` Chris Ball
2012-04-12 9:46 ` Tushar Behera
2012-04-12 17:56 ` Paul Walmsley
2012-04-12 18:19 ` Chris Ball
2012-04-14 9:38 ` Paul Walmsley
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.