sdhci-esdhc-imx -- MMC 10x slower than it should be

Commit Message

Pavel Machek June 15, 2011, 9:40 a.m. UTC

Hi!

We are seeing issues with sdhci-esdhc-imx in 2.6.39; performance is
not what it should be; it is about 10x lower in fact.

(
2.6.39 -mostly-vanilla:

dd if=/dev/mmcblk0 of=/dev/null bs=1024 count=10240
<7>sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001

takes cca 17 seconds.

2.6.34 -with-freescale-patches:

dd if=/dev/mmcblk0 of=/dev/null bs=1024 count=10240
takes about 1 second.
)

I could not pinpoint why; I found following issues while debugging:

When the core asks for 52MHz, code seems to select 40MHz even when it
can do 48MHz. I was able to work around with this:

   	    */
		return;
 		case SDHCI_HOST_CONTROL:
		     /* FSL messed up here, so we can just keep those two */
	new_val = val & (SDHCI_CTRL_LED | SDHCI_CTRL_4BITBUS);

...any idea what this comment means? I'd like to eventualy support
8BITBUS...

Part of the problem is that esdhc_writeb_le() does translation of bits
into breescale format; but readb() does not do translation back, and
core code uses read-modify-write on the register, for example when
turning on the LED. What to do there? Translate back? Add shadow
variable? Get rid of read-modify-write?

Any ideas why it is slow?
								Pavel

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Wolfram Sang June 15, 2011, 10:53 a.m. UTC | #1

Hi,

> We are seeing issues with sdhci-esdhc-imx in 2.6.39; performance is
> not what it should be; it is about 10x lower in fact.

Which SoC? 25/35/51/53?

> ...any idea what this comment means? I'd like to eventualy support
> 8BITBUS...

8-Bit bus is not specified in the standard, so it cannot be detected.
Check other drivers where they use MMC_CAP_8_BIT_DATA.

> Part of the problem is that esdhc_writeb_le() does translation of bits
> into breescale format; but readb() does not do translation back, and
> core code uses read-modify-write on the register, for example when
> turning on the LED. What to do there? Translate back? Add shadow
> variable? Get rid of read-modify-write?

Probably the least ugly solution :/

> Any ideas why it is slow?

Your board polls for card-detect, Shawn recently sent a series which
lets you fix that for mx5.

ADMA is marked broken in mainline, cause it didn't work with a number of
cards. Richard sent a patch recently.

Both series could need some more testing :)

Regards,

   Wolfram

Shawn Guo June 15, 2011, 11:24 a.m. UTC | #2

On Wed, Jun 15, 2011 at 12:53:18PM +0200, Wolfram Sang wrote:
> Hi,
> 
> > We are seeing issues with sdhci-esdhc-imx in 2.6.39; performance is
> > not what it should be; it is about 10x lower in fact.
> 
> Which SoC? 25/35/51/53?
> 
> > ...any idea what this comment means? I'd like to eventualy support
> > 8BITBUS...
> 
> 8-Bit bus is not specified in the standard, so it cannot be detected.
> Check other drivers where they use MMC_CAP_8_BIT_DATA.
> 
> > Part of the problem is that esdhc_writeb_le() does translation of bits
> > into breescale format; but readb() does not do translation back, and
> > core code uses read-modify-write on the register, for example when
> > turning on the LED. What to do there? Translate back? Add shadow
> > variable? Get rid of read-modify-write?
> 
> Probably the least ugly solution :/
> 
> > Any ideas why it is slow?
> 
> Your board polls for card-detect, Shawn recently sent a series which
> lets you fix that for mx5.
> 
> ADMA is marked broken in mainline, cause it didn't work with a number of
> cards. Richard sent a patch recently.
> 
The ADMA support is recently added into Freescale BSP.  IOW, the ADMA
does not play on kernel "2.6.34 -with-freescale-patches" either.

Pavel Machek June 15, 2011, 12:30 p.m. UTC | #3

Hi!

> > We are seeing issues with sdhci-esdhc-imx in 2.6.39; performance is
> > not what it should be; it is about 10x lower in fact.
> 
> Which SoC? 25/35/51/53?

It is on

Hardware        : Freescale MX25 3-Stack Board
Revision        : 25010

...so MX25 AFAICT.

> > Any ideas why it is slow?
> 
> Your board polls for card-detect, Shawn recently sent a series which
> lets you fix that for mx5.

Thanks, I'll check.
								Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff -u -r1.1 sdhci-esdhc.h
--- sdhci-esdhc.h	14 Jun 2011 13:04:27 -0000	1.1
+++ sdhci-esdhc.h	15 Jun 2011 08:28:25 -0000
@@ -59,10 +59,12 @@ 
   while (host->max_clk / pre_div / 16 > clock && pre_div < 256)
   	 pre_div *= 2;
 
+	pre_div /= 2; 
+
	while (host->max_clk / pre_div / div > clock && div < 16)
 	      div++;
 
...but then it sometimes produces higher frequency then
requested. mx_sdhci driver does something way more complex here.

+++ sdhci-esdhc-imx.c	15 Jun 2011 08:28:25 -0000
@@ -164,11 +166,24 @@