From owner-freebsd-arm@FreeBSD.ORG Sun Jul 24 14:34:25 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 65B781065670 for ; Sun, 24 Jul 2011 14:34:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4B09E8FC0A for ; Sun, 24 Jul 2011 14:34:24 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta12.emeryville.ca.mail.comcast.net with comcast id BqJe1h0021HpZEsACqMC0f; Sun, 24 Jul 2011 14:21:12 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta14.emeryville.ca.mail.comcast.net with comcast id BqMC1h0044NgCEG8aqMC1P; Sun, 24 Jul 2011 14:21:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p6OEL7WT056341; Sun, 24 Jul 2011 08:21:08 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: jakub.klama@uj.edu.pl In-Reply-To: References: Content-Type: text/plain Date: Sun, 24 Jul 2011 08:21:07 -0600 Message-Id: <1311517267.1589.7.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: LPC32x0 MMC/SD and DMA interface issues 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: Sun, 24 Jul 2011 14:34:25 -0000 Have a look at the Atmel driver in sys/arm/at91/at91_mci.c. It interfaces to the mmc/sd driver code in sys/dev, and uses DMA. The driver in -current does only single-block transfers; if you add my patches from http://www.freebsd.org/cgi/query-pr.cgi?pr=155214 it will do multiblock transfers as well. The controller in the first generation Atmel SoC also doesn't stop the data clock on a receive overrun even in DMA mode, which prevents using 4-bit transfers when other memory-intensive devices are active (such as the USB host) or when interrupt latency is high. I've read that the more recent Atmel chips can do so (but I haven't gotten to work with one yet). -- Ian On Sun, 2011-07-24 at 04:18 +0200, jakub.klama@uj.edu.pl wrote: > Hi, > > During my GSoC work on LPC32x0 port, I've discovered that > ARM PL180 MMC/SD controller present in SoC has completely > useless PIO mode. That is, controller can't stop card clock > when Rx FIFO buffer is full. This leads to permanent Rx > overrun errors when CPU doesn't react to arriving data as > fast as it should. Any other interrupt arriving between > reading two blocks of data from SD card will make whole > transfer fail. In practice, to make it work reasonably > reliable in PIO mode, card clock speed should be lowered > to less than 1MHz (while current SDHC cards can go with > clocks of about 30MHz). > > I think that only possibility to make this controller > working reasonable is to use DMA. On LPC32x0, there is > central general-purpose DMA controller. > > And there is my central question: how to interface DMA > controller driver with MMC/SD driver? Using direct > function calls between drivers? My work from previous > GSoC, Generic DMA Framework isn't ready to integrate > right now, at least not that fast to do this in current > GSoC timeline. Bearing in mind that it will be more or > less temporary solution, will direct function calls > between two drivers sufficient? Or maybe incorporate > whole DMA-dealing code in MMC/SD driver? > > Regards, > Jakub Klama > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"