arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards

[Warner Losh]

On 03/02/2011 17:56, Greg Ansley wrote:
> On 3/2/11 7:40 PM, Ian Lepore wrote:
>> The following reply was made to PR arm/155214; it has been noted by 
>> GNATS.
>>
>> From: Ian Lepore<freebsd at damnhippie.dyndns.org>
>> To: ticso at cicely.de
>> Cc: FreeBSD-gnats-submit at freebsd.org
>> Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern
>>   large SD cards
>> Date: Wed, 02 Mar 2011 17:21:09 -0700
>>
>>   On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote:
>> >  On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote:
>> > >
>> > > >Number:         155214
>> > > >Category:       arm
>> > > >Synopsis:       [patch] MMC/SD IO slow on Atmel ARM with modern 
>> large SD cards
>> > > >Confidential:   no
>> > > >Severity:       serious
>> > > >Priority:       medium
>> > > >Responsible:    freebsd-arm
>> > > >State:          open
>> > > >Quarter:
>> > > >Keywords:
>> > > >Date-Required:
>> > > >Class:          sw-bug
>> > > >Submitter-Id:   current-users
>> > > >Arrival-Date:   Wed Mar 02 22:10:10 UTC 2011
>> > > >Closed-Date:
>> > > >Last-Modified:
>> > > >Originator:     Ian Lepore<freebsd at damnhippie.dyndns.org>
>> > > >Release:        FreeBSD 8.2-RC3 arm
>> > > >Organization:
>> > >  none
>> > > >Environment:
>> > >  FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 
>> 2011     root at revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB  arm
>> > >
>> > >  Included patch is against -current even though the problem was 
>> first seen on
>> > >  8.2-RC3
>> > >
>> > >  The problem was seen on AT91RM9200 hardware, but presumably also 
>> affects the
>> > >  SAM9 series which uses the same driver code.
>> > >
>> > > >Description:
>> > >  With the latest generation of large-capacity SD cards, write 
>> speeds as low as
>> > >  20 kbytes/sec are seen.  These modern cards have erase-block 
>> sizes as large as
>> > >  8192K (compared to 32K typical on previous generations).  The 
>> at91_mci driver
>> > >  does only single-sector IO; apparently this requires the SD card 
>> to internally
>> > >  perform an expensive read-erase-modify-write cycle for each 512 
>> byte block
>> > >  written to the card.
>> >
>> >  The complete details of this problem are completely known.
>> >  However the RM9200 has many hardware problems to be worked around and
>> >  so far noone actually did.
>> >  Your patch is quite large, so I would like to ask you explicitly:
>> >  Did you test your patch with an AT91RM9200 system?
>> >  You did enable multisector support for reading and (more 
>> important) for
>> >  writing?
>> >  But you didn't activate 4bit mode?
>> >  With 4bit mode there is no hardware bug, but when the driver was 
>> written
>> >  is was just done in a lazy way because activating 4bit on SD cards 
>> require
>> >  special handling - in the meantime the SD layer itself was 
>> extracted and
>> >  has 4bit support, but the at91_mci driver was never updated to use 
>> that.
>> >
>> >  PS: I'm very pleased to see your work since SD write speed was a
>> >  major show stopper for some applications
>> >
>>
>>   Yes, the patch is large, partly because I included comments about the
>>   hardware problems I found and how the code works around them (and also
>>   to help the next person understand the flow).
>>
>>   My changes support multi-sector IO for both reads and writes.
>>
>>   The company I work for uses the AT91RM9200 on custom-designed 
>> boards in
>>   8 products, all with substantially similar board designs.  So far 
>> we've
>>   tested these changes on 4 of them, with no problems found.
>>
>>   I have not tested with 4-bit enabled; I wasn't aware (but in 
>> retrospect
>>   I probably should have assumed) that the hardware bugs are different
>>   with 4-bit enabled.  I'm not even sure our hardware design carries 
>> all 4
>>   lines to the card; I'll look at the schematics and if they're 
>> connected
>>   I'll see about testing that mode.  (And if they're not I'll see about
>>   having our designers wire up all 4 lines on future designs.)
>>
>>   I also haven't tested with the SAM9-series, because I don't have that
>>   hardware available.  (I hope to convince our hardware designers to
>>   migrate us to SAM9 this year.)
>>
> With the current code (prepatch) 4bit mode is known to work at least 
> on the SAM9G20 with kernel option AT91_MCI_HAS_4WIRE.  I'll be working 
> on the SAM9G20 in the next few days and I can test the patch on both a 
> RM9200 (1 bit only) and on a couple of SAM9G20 designs with 4bit 
> hardware.

For some ancient history...

The Atmel Linux repo went back and forth on the 4-bit support in 
RM9200.  When the SAM9260 was released, they added support there and 
specifically disabled it for the RM9200.  When I asked about it, they 
muttered something about silicon bugs.  After that, it ping ponged back 
and forth between supported and not for a while.  I honestly don't know 
where it settled finally.

Warner