MCI support for AT91 family processors.

Fixed to parse CSD correctly on little endian processors as gcc orders bitfields differently between big and little endian ones.

include/asm-arm/arch-at91/clk.h +0 -0

index f642dd9..26b537c 100644
@@ -54,6 +54,11 @@ static inline unsigned long get_spi_clk_rate(unsigned int dev_id)
 	return get_mck_clk_rate();

cpu/arm926ejs/at91/at91cap9_devices.c +0 -0

index 39e405f..2dc1984 100644

cpu/arm926ejs/at91/at91cap9_devices.c +12 -0

+		case 0:
+			at91_set_A_periph(AT91_PIN_PA17, 1);
+			at91_set_A_periph(AT91_PIN_PA18, 1);
+			at91_set_A_periph(AT91_PIN_PA19, 1);
+			at91_set_A_periph(AT91_PIN_PA20, 1);
+			at91_set_A_periph(AT91_PIN_PA21, 1);
+			break;
+	}
+}
+#endif
+#endif
+

include/asm-arm/arch-at91/hardware.h +0 -0

index de06a10..6430ade 100644

please use MCI0_BASE and MCI1_BASE so we can detect if the soc support multiple mci and please move it to soc header
I'll send a patch to clean the other

Oh ... I had a more recent patch, but looks like it didn't make it to the list. It already fixes a large parts of your comments. Thanks for the review

Quoted 3 lines

please use MCI0_BASE and MCI1_BASE so we can detect if the soc support multiple mci and please move it to soc header
I'll send a patch to clean the other

I'm not sure what other you're talking about

Quoted 2 lines · Sami Kantoluoto

Fixed to parse CSD correctly on little endian processors as gcc orders bitfields differently between big and little endian ones.

Please also see this patch, which will fix those bugs as weel, while switching to the new GENRIC_MMC API:
http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
I'd highly appreciate if you could test it, to get some feedback

the configuration for the MCI controller, which should be done in the at91sam*_devices.c files. See the attached patch (relying on the patch mentionned above) that adds such support. It's not complete yet either: it partially lacks support for models which have 2 MCI controllers, but that's not the case of the 9G20 anyway (that's just a matter of putting proper ifdefs before defining AT91_BASE_MCI).
If what I've done in this patch is not the way to go, I'd appreciate guidance on how to do it correctly.

Quoted 8 lines · Albin Tonnerre

Quoted 2 lines · Sami Kantoluoto

Fixed to parse CSD correctly on little endian processors as gcc orders bitfields differently between big and little endian ones.

Please also see this patch, which will fix those bugs as weel, while switching to the new GENRIC_MMC API:
http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
I'd highly appreciate if you could test it, to get some feedback

Thanks, I'll test when I get some time later this week but I think (by reading the patch so I probably missed something) it won't solve the CSD problem. The real reason of the "CSD problem" of course is that how the mmc_csd structure is defined (host byte order not taken in account or at least how gcc handles bitfields).

[snip]

Quoted 8 lines

the configuration for the MCI controller, which should be done in the at91sam*_devices.c files. See the attached patch (relying on the patch mentionned above) that adds such support. It's not complete yet either: it partially lacks support for models which have 2 MCI controllers, but that's not the case of the 9G20 anyway (that's just a matter of putting proper ifdefs before defining AT91_BASE_MCI).
If what I've done in this patch is not the way to go, I'd appreciate guidance on how to do it correctly.

It seems ok to me except one comment about the interface:

include/asm-arm/arch-at91/at91_common.h

Quoted 4 lines

include/asm-arm/arch-at91/at91_common.h +2 -0

 
+void at91_mci0_hw_init(int);
+void at91_mci1_hw_init(int);

I'm just wondering if the bus width should be configurable. It's probably quite unusual to use just one data bit but not impossible though. So maybe the interface call could be:

void at91_mci0_hw_init(int bwForSlotA, bwForSlotB)

Where the bwForSlot<X> is either 0 (which means slot is not used), 1 or 4.

Quoted 10 lines · Sami Kantoluoto

Quoted 8 lines · Albin Tonnerre

Quoted 2 lines · Sami Kantoluoto

Fixed to parse CSD correctly on little endian processors as gcc orders bitfields differently between big and little endian ones.

Please also see this patch, which will fix those bugs as weel, while switching to the new GENRIC_MMC API:
http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
I'd highly appreciate if you could test it, to get some feedback

Quoted 5 lines

Thanks, I'll test when I get some time later this week but I think (by reading the patch so I probably missed something) it won't solve the CSD problem. The real reason of the "CSD problem" of course is that how the mmc_csd structure is defined (host byte order not taken in account or at least how gcc handles bitfields).

drivers/mmc/mmc.c does not actually use the bitfield to parse the csd struct, and got fixed a while back to work no matter what endianness you're using, so it should solve it anyway.

Quoted 10 lines · Sami Kantoluoto

Quoted 8 lines · Albin Tonnerre

Quoted 2 lines · Sami Kantoluoto

Fixed to parse CSD correctly on little endian processors as gcc orders bitfields differently between big and little endian ones.

Please also see this patch, which will fix those bugs as weel, while switching to the new GENRIC_MMC API:
http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
I'd highly appreciate if you could test it, to get some feedback

Quoted 6 lines

Thanks, I'll test when I get some time later this week but I think (by reading the patch so I probably missed something) it won't solve the CSD problem. The real reason of the "CSD problem" of course is that how the mmc_csd structure is defined (host byte order not taken in account or at least how gcc handles bitfields).

drivers/mmc/mmc.c does not actually use the bitfield to parse the csd struct, and got fixed a while back to work no matter what endianness you're using, so it should solve it anyway.

Fixed to parse CSD correctly on little endian processors as gcc orders bitfields differently between big and little endian ones.

Signed-off-by Sami Kantoluoto <[email protected]>

static void mmc_dump_cid(const struct mmc_cid *cid) {

drivers/mmc/atmel_mci.c +0 -0

 	printf("Manufacturer ID:       %02X\n", cid->mid);

drivers/mmc/atmel_mci.c +3 -1

 	mmc_rca = resp[0] >> 16;

@@ -468,6 +515,7 @@ int mmc_legacy_init(int verbose)
 	struct mmc_cid cid;
 	struct mmc_csd csd;
 	unsigned int max_blksz;
+	unsigned long resp[4];
 	int ret;
 
 	/* Initialize controller */

@@ -488,9 +536,10 @@ int mmc_legacy_init(int verbose)
 		return ret;
 
 	/* Get CSD from the card */
-	ret = mmc_cmd(MMC_CMD_SEND_CSD, mmc_rca << 16, &csd, R2 | NCR);
+	ret = mmc_cmd(MMC_CMD_SEND_CSD, mmc_rca << 16, resp, R2 | NCR);
 	if (ret)
 		return ret;
+	mmc_parse_csd(&csd, resp);
 	if (verbose)
 		mmc_dump_csd(&csd);
 

include/asm-arm/arch-at91/clk.h +0 -0

index f642dd9..26b537c 100644
@@ -54,6 +54,11 @@ static inline unsigned long get_spi_clk_rate(unsigned int dev_id)
 	return get_mck_clk_rate();