From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 19:55:28 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF8C1065679 for ; Thu, 3 Mar 2011 19:55:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA108FC1E for ; Thu, 3 Mar 2011 19:55:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p23JpnCR073752 for ; Thu, 3 Mar 2011 12:51:49 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D6FF142.9020801@bsdimp.com> Date: Thu, 03 Mar 2011 12:51:30 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201103030040.p230eBIt023558@freefall.freebsd.org> <4D6EE744.5050100@ansley.com> In-Reply-To: <4D6EE744.5050100@ansley.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:55:28 -0000 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 >> To: ticso@cicely.de >> Cc: FreeBSD-gnats-submit@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 >> > > >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@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