aboutsummaryrefslogtreecommitdiff
path: root/arch/avr32/boards
diff options
context:
space:
mode:
authorHaavard Skinnemoen <haavard.skinnemoen@atmel.com>2008-06-30 18:35:03 +0200
committerPierre Ossman <drzeus@drzeus.cx>2008-07-15 14:14:49 +0200
commit7d2be0749a59096a334c94dc48f43294193cb8ed (patch)
treea14faa58c61071fb548c223268650153b5aa865a /arch/avr32/boards
parent6d37333163025b46afbcad434ec9a5f2e88e7254 (diff)
atmel-mci: Driver for Atmel on-chip MMC controllers
This is a driver for the MMC controller on the AP7000 chips from Atmel. It should in theory work on AT91 systems too with some tweaking, but since the DMA interface is quite different, it's not entirely clear if it's worth merging this with the at91_mci driver. This driver has been around for a while in BSPs and kernel sources provided by Atmel, but this particular version uses the generic DMA Engine framework (with the slave extensions) instead of an avr32-only DMA controller framework. This driver can also use PIO transfers when no DMA channels are available, and for transfers where using DMA may be difficult or impractical for some reason (e.g. the DMA setup overhead is usually not worth it for very short transfers, and badly aligned buffers or lengths are difficult to handle.) Currently, the driver only support PIO transfers. DMA support has been split out to a separate patch to hopefully make it easier to review. The driver has been tested using mmc-block and ext3fs on several SD, SDHC and MMC+ cards. Reads and writes work fine, with read transfer rates up to 3.5 MiB/s on fast cards with debugging disabled. The driver has also been tested using the mmc_test module on the same cards. All tests except 7, 9, 15 and 17 succeed. The first two are unsupported by all the cards I have, so I don't know if the driver handles this correctly. The last two fail because the hardware flags a Data CRC Error instead of a Data Timeout error. I'm not sure how to deal with that. Documentation for this controller can be found in many data sheets from Atmel, including the AT32AP7000 data sheet which can be found here: http://www.atmel.com/dyn/products/datasheets.asp?family_id=682 Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Diffstat (limited to 'arch/avr32/boards')
-rw-r--r--arch/avr32/boards/atngw100/setup.c7
-rw-r--r--arch/avr32/boards/atstk1000/atstk1002.c3
2 files changed, 10 insertions, 0 deletions
diff --git a/arch/avr32/boards/atngw100/setup.c b/arch/avr32/boards/atngw100/setup.c
index a51bb9fb3c8..c7fe94d03a1 100644
--- a/arch/avr32/boards/atngw100/setup.c
+++ b/arch/avr32/boards/atngw100/setup.c
@@ -19,6 +19,7 @@
#include <linux/leds.h>
#include <linux/spi/spi.h>
+#include <asm/atmel-mci.h>
#include <asm/io.h>
#include <asm/setup.h>
@@ -51,6 +52,11 @@ static struct spi_board_info spi0_board_info[] __initdata = {
},
};
+static struct mci_platform_data __initdata mci0_data = {
+ .detect_pin = GPIO_PIN_PC(25),
+ .wp_pin = GPIO_PIN_PE(0),
+};
+
/*
* The next two functions should go away as the boot loader is
* supposed to initialize the macb address registers with a valid
@@ -170,6 +176,7 @@ static int __init atngw100_init(void)
set_hw_addr(at32_add_device_eth(1, &eth_data[1]));
at32_add_device_spi(0, spi0_board_info, ARRAY_SIZE(spi0_board_info));
+ at32_add_device_mci(0, &mci0_data);
at32_add_device_usba(0, NULL);
for (i = 0; i < ARRAY_SIZE(ngw_leds); i++) {
diff --git a/arch/avr32/boards/atstk1000/atstk1002.c b/arch/avr32/boards/atstk1000/atstk1002.c
index 86b363c1c25..e11659b732f 100644
--- a/arch/avr32/boards/atstk1000/atstk1002.c
+++ b/arch/avr32/boards/atstk1000/atstk1002.c
@@ -234,6 +234,9 @@ static int __init atstk1002_init(void)
#ifdef CONFIG_BOARD_ATSTK100X_SPI1
at32_add_device_spi(1, spi1_board_info, ARRAY_SIZE(spi1_board_info));
#endif
+#ifndef CONFIG_BOARD_ATSTK1002_SW2_CUSTOM
+ at32_add_device_mci(0, NULL);
+#endif
#ifdef CONFIG_BOARD_ATSTK1002_SW5_CUSTOM
set_hw_addr(at32_add_device_eth(1, &eth_data[1]));
#else