From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 03:07:29 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 C2696106564A for ; Thu, 3 Mar 2011 03:07:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0AE8FC15 for ; Thu, 3 Mar 2011 03:07:28 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p232oZb7071079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 03:50:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p232oWYK094151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2011 03:50:32 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p232oVSx026439; Thu, 3 Mar 2011 03:50:31 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p232oVxr026438; Thu, 3 Mar 2011 03:50:31 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2011 03:50:31 +0100 From: Bernd Walter To: Greg Ansley Message-ID: <20110303025031.GD86812@cicely7.cicely.de> References: <201103030040.p230eBIt023558@freefall.freebsd.org> <4D6EE744.5050100@ansley.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6EE744.5050100@ansley.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org 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 Reply-To: ticso@cicely.de 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 03:07:29 -0000 On Wed, Mar 02, 2011 at 07:56:36PM -0500, 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. Oh - we already have such a feature - cool. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.