Date: Sun, 24 Jul 2011 08:21:07 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: jakub.klama@uj.edu.pl Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org, andrew@fubar.geek.nz Subject: Re: LPC32x0 MMC/SD and DMA interface issues Message-ID: <1311517267.1589.7.camel@revolution.hippie.lan> In-Reply-To: <bafc2a2fd71aafcac183678ceb584fd7@uj.edu.pl> References: <bafc2a2fd71aafcac183678ceb584fd7@uj.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1311517267.1589.7.camel>