From: "Eric Bénard" <eric@eukrea.com>
To: joancarles <joancarles@fqingenieria.es>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
Zhu Richard-R65037 <r65037@freescale.com>,
shawn.guo@linaro.org, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [MX25][MMC] mmc esdhc failure in 3.3
Date: Tue, 27 Mar 2012 11:40:48 +0200 [thread overview]
Message-ID: <20120327114048.6af2e178@eb-e6520> (raw)
In-Reply-To: <7f2ae9e3800848e140461a0506808fb4@mail.fqingenieria.es>
Hi,
Le Tue, 27 Mar 2012 11:33:57 +0200,
joancarles <joancarles@fqingenieria.es> a écrit :
> >> Interesting question is now why it worked on your older kernel? The
> >> code
> >> around BROKEN_TIMEOUT is there for much longer, I'd think.
> >>
> > not in fact it seems to have been broken from a long time and I think
> > I'm responsible of that in 37865fe91582582a6f6c00652f6a2b1ff71f8a78
> > "mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhc"
> > because unlike the i.MX35 it seems that the i.MX25 manages to read
> > properly the partition table even without the timeout quirk and it
> > seems that I didn't do more extensive tests for this patch.
>
> Might be unrelated, however I have been keeping my eyes on the fix of
> ENGcm07207 quirk introduced with 16a790bcc. According to the
> IMX25CE.pdf, to abort data transfers on the AHB, software can reset the
> eSDHC by writing 1 to SYSCTL[24] (RSTA), which currently is not done
> with SDHCI_QUIRK_NO_MULTIBLOCK. It sets the max_blk_count to 1 instead
> of 65535. Not sure if this is also limiting the speed.
>
I tried to increase max_blk_count and it breaks after a few tests.
Using an oscilloscope it seems we have a big latency between each
transfer which could explain the low throughput, I didn't have the
time to look deeper at this problem.
> I have tried putting the SD card into an ALL-in-One reader via USB and
> I get 6MB/s read and 15MB/s write performance. Since I didn't know the
> exact class of the card, this reassures me that there is nothing
> substantially wrong with the card per se.
>
> So, how can we find a solution to this speed issue? Also, do you plan
> on submitting your patch to revert the timeout quirk for MX25?
>
yes, I'm writing a proper commit message and will send it in a few
minutes.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: eric@eukrea.com (Eric Bénard)
To: linux-arm-kernel@lists.infradead.org
Subject: [MX25][MMC] mmc esdhc failure in 3.3
Date: Tue, 27 Mar 2012 11:40:48 +0200 [thread overview]
Message-ID: <20120327114048.6af2e178@eb-e6520> (raw)
In-Reply-To: <7f2ae9e3800848e140461a0506808fb4@mail.fqingenieria.es>
Hi,
Le Tue, 27 Mar 2012 11:33:57 +0200,
joancarles <joancarles@fqingenieria.es> a ?crit :
> >> Interesting question is now why it worked on your older kernel? The
> >> code
> >> around BROKEN_TIMEOUT is there for much longer, I'd think.
> >>
> > not in fact it seems to have been broken from a long time and I think
> > I'm responsible of that in 37865fe91582582a6f6c00652f6a2b1ff71f8a78
> > "mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhc"
> > because unlike the i.MX35 it seems that the i.MX25 manages to read
> > properly the partition table even without the timeout quirk and it
> > seems that I didn't do more extensive tests for this patch.
>
> Might be unrelated, however I have been keeping my eyes on the fix of
> ENGcm07207 quirk introduced with 16a790bcc. According to the
> IMX25CE.pdf, to abort data transfers on the AHB, software can reset the
> eSDHC by writing 1 to SYSCTL[24] (RSTA), which currently is not done
> with SDHCI_QUIRK_NO_MULTIBLOCK. It sets the max_blk_count to 1 instead
> of 65535. Not sure if this is also limiting the speed.
>
I tried to increase max_blk_count and it breaks after a few tests.
Using an oscilloscope it seems we have a big latency between each
transfer which could explain the low throughput, I didn't have the
time to look deeper at this problem.
> I have tried putting the SD card into an ALL-in-One reader via USB and
> I get 6MB/s read and 15MB/s write performance. Since I didn't know the
> exact class of the card, this reassures me that there is nothing
> substantially wrong with the card per se.
>
> So, how can we find a solution to this speed issue? Also, do you plan
> on submitting your patch to revert the timeout quirk for MX25?
>
yes, I'm writing a proper commit message and will send it in a few
minutes.
Eric
next prev parent reply other threads:[~2012-03-27 9:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 11:29 [MX25][MMC] mmc esdhc failure in 3.3-rc5 joancarles
2012-03-12 13:12 ` [MX25][MMC] mmc esdhc failure in 3.3-rc5 (still present in rc7) joancarles
2012-03-12 13:12 ` joancarles
2012-03-12 13:24 ` [MX25][MMC] mmc esdhc failure in 3.3-rc5 Wolfram Sang
2012-03-12 14:50 ` joancarles
2012-03-12 21:45 ` Wolfram Sang
2012-03-13 11:20 ` joancarles
2012-03-13 5:55 ` Zhu Richard-R65037
2012-03-16 15:03 ` joancarles
2012-03-27 7:32 ` [MX25][MMC] mmc esdhc failure in 3.3 joancarles
2012-03-27 7:32 ` joancarles
2012-03-27 7:59 ` joancarles
2012-03-27 7:59 ` joancarles
2012-03-27 8:12 ` Eric Bénard
2012-03-27 8:12 ` Eric Bénard
2012-03-27 8:46 ` joancarles
2012-03-27 8:46 ` joancarles
2012-03-27 8:58 ` Eric Bénard
2012-03-27 8:58 ` Eric Bénard
2012-03-27 13:03 ` Zhu Richard-R65037
2012-03-27 13:03 ` Zhu Richard-R65037
2012-03-27 9:01 ` Wolfram Sang
2012-03-27 9:01 ` Wolfram Sang
2012-03-27 9:06 ` Eric Bénard
2012-03-27 9:06 ` Eric Bénard
2012-03-27 9:14 ` Wolfram Sang
2012-03-27 9:14 ` Wolfram Sang
2012-03-27 9:23 ` Eric Bénard
2012-03-27 9:23 ` Eric Bénard
2012-03-27 9:36 ` Wolfram Sang
2012-03-27 9:36 ` Wolfram Sang
2012-03-27 9:33 ` joancarles
2012-03-27 9:33 ` joancarles
2012-03-27 9:40 ` Eric Bénard [this message]
2012-03-27 9:40 ` Eric Bénard
2012-03-27 10:56 ` joancarles
2012-03-27 10:56 ` joancarles
2012-03-28 9:26 ` joancarles
2012-03-28 9:26 ` joancarles
2012-03-28 14:01 ` joancarles
2012-03-28 14:01 ` joancarles
2012-03-27 9:45 ` Wolfram Sang
2012-03-27 9:45 ` Wolfram Sang
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=20120327114048.6af2e178@eb-e6520 \
--to=eric@eukrea.com \
--cc=joancarles@fqingenieria.es \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=r65037@freescale.com \
--cc=shawn.guo@linaro.org \
--cc=w.sang@pengutronix.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.