From owner-freebsd-arm@FreeBSD.ORG Mon Apr 18 20:07:30 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 4D6C010657C4 for ; Mon, 18 Apr 2011 20:07:30 +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 0A5A18FC21 for ; Mon, 18 Apr 2011 20:07:29 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3IK2CPv041974 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2011 14:02:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201104181900.p3IJ0OWs079642@freefall.freebsd.org> Date: Mon, 18 Apr 2011 14:02:52 -0600 Content-Transfer-Encoding: 7bit Message-Id: <2578F555-AFF8-405D-ACA2-914A765FE4BC@bsdimp.com> References: <201104181900.p3IJ0OWs079642@freefall.freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 18 Apr 2011 14:02:51 -0600 (MDT) 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 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:07:30 -0000 On Apr 18, 2011, at 1:00 PM, Ian Lepore wrote: > The following reply was made to PR arm/155214; it has been noted by GNATS. > > From: Ian Lepore > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern > large SD cards > Date: Mon, 18 Apr 2011 12:45:28 -0600 > > I have an updated patch for this which includes better error handling, > and better read performance (mainly by splitting large IO requests into > two DMA operations and doing the byte-swapping for the first half while > the second half is still on the wire from the card). It also has more > comments about what works and what doesn't (ex: 30mhz 4-bit transfers > when USB Host mode is also enabled). > > I don't see any straightforward way on the PR page to nuke the original > patch and supply a replacement. What's the best way to handle that? Just submit the patch as a followup. Warner