LPC32x0 MMC/SD and DMA interface issues
Ian Lepore
freebsd at damnhippie.dyndns.org
Sun Jul 24 14:34:25 UTC 2011
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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
More information about the freebsd-hackers
mailing list