Skip to contentSkip to conversation

split MMC_CAP_4_BIT_DATA

PATCH In review Mike Frysinger 5 participants 27 messages Jan 8, 2008 – Jan 12, 2008

Subsystems (7)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 split MMC_CAP_4_BIT_DATA

The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of MMC_CAP_4_BIT_DATA meaning "your host controller can do 1-bit or 4-bit for all modes" is insufficient for our needs. The attached patch splits MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and updates all host controllers to include these in their caps and then changes existing code to check the new defines. At the moment, SD/SDIO are lumped into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and SDIO as well while I'm doing this ?

---

drivers/mmc/core/mmc.c +1 -1
index 68c0e3b..ca12db7 100644
@@ -397,7 +397,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 	 * Activate wide bus (if supported).
 	 */
 	if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
-		(host->caps & MMC_CAP_4_BIT_DATA)) {
+		(host->caps & MMC_CAP_MMC_4_BIT_DATA)) {
 		err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
 			EXT_CSD_BUS_WIDTH, EXT_CSD_BUS_WIDTH_4);
 		if (err)
drivers/mmc/core/sd.c +1 -1
index d1c1e0f..974b63d 100644
@@ -441,7 +441,7 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
 	/*
 	 * Switch to wider bus (if supported).
 	 */
-	if ((host->caps & MMC_CAP_4_BIT_DATA) &&
+	if ((host->caps & MMC_CAP_SD_4_BIT_DATA) &&
 		(card->scr.bus_widths & SD_SCR_BUS_WIDTH_4)) {
 		err = mmc_app_set_bus_width(card, MMC_BUS_WIDTH_4);
 		if (err)
drivers/mmc/core/sdio.c +1 -1
index 87a50f4..1d389c8 100644
@@ -143,7 +143,7 @@ static int sdio_enable_wide(struct mmc_card *card)
 	int ret;
 	u8 ctrl;
 
-	if (!(card->host->caps & MMC_CAP_4_BIT_DATA))
+	if (!(card->host->caps & MMC_CAP_SD_4_BIT_DATA))
 		return 0;
 
 	if (card->cccr.low_speed && !card->cccr.wide_bus)
drivers/mmc/host/at91_mci.c +1 -1
index b1edcef..63d89b0 100644
@@ -851,7 +851,7 @@ static int __init at91_mci_probe(struct platform_device *pdev)
 	host->board = pdev->dev.platform_data;
 	if (host->board->wire4) {
 		if (cpu_is_at91sam9260() || cpu_is_at91sam9263())
-			mmc->caps |= MMC_CAP_4_BIT_DATA;
+			mmc->caps |= (MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA);
 		else
 			printk("AT91 MMC: 4 wire bus mode not supported"
 				" - using 1 wire\n");
drivers/mmc/host/imxmmc.c +1 -1
index f2070a1..67d4bc0 100644
@@ -975,7 +975,7 @@ static int imxmci_probe(struct platform_device *pdev)
 	mmc->f_min = 150000;
 	mmc->f_max = CLK_RATE/2;
 	mmc->ocr_avail = MMC_VDD_32_33;
-	mmc->caps = MMC_CAP_4_BIT_DATA;
+	mmc->caps = (MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA);
 
 	/* MMC core transfer sizes tunable parameters */
 	mmc->max_hw_segs = 64;
drivers/mmc/host/omap.c +1 -1
index 971e18b..b1ae793 100644
@@ -1079,7 +1079,7 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
 	mmc->caps = MMC_CAP_MULTIWRITE | MMC_CAP_BYTEBLOCK;
 
 	if (minfo->wire4)
-		 mmc->caps |= MMC_CAP_4_BIT_DATA;
+		 mmc->caps |= (MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA);
 
 	/* Use scatterlist DMA to reduce per-transfer costs.
 	 * NOTE max_seg_size assumption that small blocks aren't
drivers/mmc/host/pxamci.c +1 -1
index 1654a33..4fa00f1 100644
@@ -527,7 +527,7 @@ static int pxamci_probe(struct platform_device *pdev)
 	mmc->caps = 0;
 	host->cmdat = 0;
 	if (!cpu_is_pxa21x() && !cpu_is_pxa25x()) {
-		mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
+		mmc->caps |= MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
 		host->cmdat |= CMDAT_SDIO_INT_EN;
 	}
 
drivers/mmc/host/sdhci.c +1 -1
index 785bbdc..09c4358 100644
@@ -1405,7 +1405,7 @@ static int __devinit sdhci_probe_slot(struct pci_dev *pdev, int slot)
 	mmc->ops = &sdhci_ops;
 	mmc->f_min = host->max_clk / 256;
 	mmc->f_max = host->max_clk;
-	mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MULTIWRITE | MMC_CAP_SDIO_IRQ;
+	mmc->caps = MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_MULTIWRITE | MMC_CAP_SDIO_IRQ;
 
 	if (caps & SDHCI_CAN_DO_HISPD)
 		mmc->caps |= MMC_CAP_SD_HIGHSPEED;
drivers/mmc/host/tifm_sd.c +1 -1
index 20d5c7b..78cad6b 100644
@@ -973,7 +973,7 @@ static int tifm_sd_probe(struct tifm_dev *sock)
 
 	mmc->ops = &tifm_sd_ops;
 	mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
-	mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MULTIWRITE;
+	mmc->caps = MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_MULTIWRITE;
 	mmc->f_min = 20000000 / 60;
 	mmc->f_max = 24000000;
 
drivers/mmc/host/wbsd.c +1 -1
index 4d5f374..70d6071 100644
@@ -1219,7 +1219,7 @@ static int __devinit wbsd_alloc_mmc(struct device *dev)
 	mmc->f_min = 375000;
 	mmc->f_max = 24000000;
 	mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
-	mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MULTIWRITE;
+	mmc->caps = MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_MULTIWRITE;
 
 	spin_lock_init(&host->lock);
 
include/linux/mmc/host.h +2 -1
index 7ab962f..142fa69 100644
@@ -88,12 +88,13 @@ struct mmc_host {
 
 	unsigned long		caps;		/* Host capabilities */
 
-#define MMC_CAP_4_BIT_DATA	(1 << 0)	/* Can the host do 4 bit transfers */
+#define MMC_CAP_SD_4_BIT_DATA	(1 << 0)	/* Can the host do SD 4 bit transfers */
 #define MMC_CAP_MULTIWRITE	(1 << 1)	/* Can accurately report bytes sent to card on error */
 #define MMC_CAP_MMC_HIGHSPEED	(1 << 2)	/* Can do MMC high-speed timing */
 #define MMC_CAP_SD_HIGHSPEED	(1 << 3)	/* Can do SD high-speed timing */
 #define MMC_CAP_SDIO_IRQ	(1 << 4)	/* Can signal pending SDIO IRQs */
 #define MMC_CAP_SPI		(1 << 5)	/* Talks only SPI protocols */
+#define MMC_CAP_MMC_4_BIT_DATA	(1 << 6)	/* Can the host do MMC 4 bit transfers */
 
 	/* host specific block data */
 	unsigned int		max_seg_size;	/* see blk_queue_max_segment_size */
#1 lore raw
Quoted 11 lines · On Tue, 8 Jan 2008 13:29:39 -0500 Mike Frysinger <[email protected]> wrote:

The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of MMC_CAP_4_BIT_DATA meaning "your host controller can do 1-bit or 4-bit for all modes" is insufficient for our needs. The attached patch splits MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and updates all host controllers to include these in their caps and then changes existing code to check the new defines. At the moment, SD/SDIO are lumped into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and SDIO as well while I'm doing this ?

I fail to see why you need to split MMC and SD. Could you elaborate why the controller won't work with MMC cards? I haven't seen any differences from SD.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#2 lore raw
Quoted 12 lines · On Tuesday 08 January 2008 14:21:57 Pierre Ossman wrote:
Quoted 11 lines · Mike Frysinger

The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of MMC_CAP_4_BIT_DATA meaning "your host controller can do 1-bit or 4-bit for all modes" is insufficient for our needs. The attached patch splits MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and updates all host controllers to include these in their caps and then changes existing code to check the new defines. At the moment, SD/SDIO are lumped into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and SDIO as well while I'm doing this ?

Quoted 5 lines
Quoted 1 line

I fail to see why you need to split MMC and SD. Could you elaborate why the controller won't work with MMC cards? I haven't seen any differences from SD.

i dont understand what's confusing. the Blackfin on chip host controller only supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it may be a stupid decision, it is what it is, and i need the framework made more flexible in order to get the Blackfin driver merged cleanly. we do software for hardware, we dont do hardware.
-mike

#3 lore raw
Quoted 6 lines · On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger <[email protected]> wrote:

i dont understand what's confusing. the Blackfin on chip host controller only supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it may be a stupid decision, it is what it is, and i need the framework made more flexible in order to get the Blackfin driver merged cleanly. we do software for hardware, we dont do hardware.

Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code.

So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#4 lore raw
Quoted 9 lines · Pierre Ossman
Quoted 5 lines · On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger <[email protected]> wrote:

i dont understand what's confusing. the Blackfin on chip host controller only supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it may be a stupid decision, it is what it is, and i need the framework made more flexible in order to get the Blackfin driver merged cleanly. we do software for hardware, we dont do hardware.

Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code.

regardless of where the limitation is, the change is necessary. however you wish to classify the issue, it doesnt matter to me. the Blackfin controller needs to declare the following capabilities:
- 1-bit MMC
- 1-bit SD / 4-bit SD
- 1-bit SDIO / 4-bit SDIO
the existing framework is not flexible enough to account for this, thus the patch posted.

Quoted 1 line

So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical.

you may be 100% correct, i have no idea, i'm not really familiar with MMC/SD/SDIO at all.
-mike

#5 lore raw
Quoted 5 lines · On Tue, 8 Jan 2008 16:44:08 -0500 "Mike Frysinger" <[email protected]> wrote:
Quoted 1 line · Pierre Ossman

So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical.

you may be 100% correct, i have no idea, i'm not really familiar with MMC/SD/SDIO at all.

The patch adds complexity to the system. So until you can convince me that complexity is actually needed, I'm afraid the answer is NAK.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#6 lore raw
In reply to Pierre Ossman
Quoted 10 lines · Pierre Ossman
Quoted 6 lines · On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger <[email protected]> wrote:

i dont understand what's confusing. the Blackfin on chip host controller only supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it may be a stupid decision, it is what it is, and i need the framework made more flexible in order to get the Blackfin driver merged cleanly. we do software for hardware, we dont do hardware.

Quoted 4 lines

Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code.

So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical.

As Mike said, the reason split this flag is because Blackfin on-chip SDIO controller's limitation.
Cliff is working on it for a long time, so I dropped him in. Hope he can clarify the confusing things.

Thanks
-Bryan Wu

#7 lore raw

Hi,all

I'd like to say something about this issue.
Currently,the blackfin on chip SD host ONLY support 1-bit MMC while support 1-bit/4-bit SD/SDIO.
And we want our driver to support both 1-bit MMC and 4-bit SD/SDIO.but the current MMC driver framework
Only allow us to set one kind of bus width,either 1-bit or 4-bit.So in order to meet our case,we need more flexible mechanism
To inform the upper commom driver to know our situation.

Cliff

-----Original Message-----
From: Bryan Wu [mailto:[email protected]]
Sent: Wednesday, January 09, 2008 10:33 AM
To: Pierre Ossman; [email protected]
Cc: Mike Frysinger; [email protected]
Subject: Re: [patch] split MMC_CAP_4_BIT_DATA

Quoted 9 lines · Pierre Ossman
Quoted 6 lines · On Tue, 8 Jan 2008 14:40:49 -0500 Mike Frysinger <[email protected]> wrote:

i dont understand what's confusing. the Blackfin on chip host controller only supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it may be a stupid decision, it is what it is, and i need the framework made more flexible in order to get the Blackfin driver merged cleanly. we do software for hardware, we

dont do hardware.

Quoted 2 lines

Well, since I've seen no _hardware_ differences between 4-bit MMC and

4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code.

Quoted 2 lines

So, again, if you feel that there is a hardware difference between

4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical.

Quoted 1 line

As Mike said, the reason split this flag is because Blackfin on-chip SDIO controller's limitation.
Cliff is working on it for a long time, so I dropped him in. Hope he can clarify the confusing things.

Thanks
-Bryan Wu

#8 lore raw
Quoted 12 lines · Cliff

Hi,all

I'd like to say something about this issue.
Currently,the blackfin on chip SD host ONLY support 1-bit MMC while support 1-bit/4-bit SD/SDIO.
And we want our driver to support both 1-bit MMC and 4-bit SD/SDIO.but the current MMC driver framework
Only allow us to set one kind of bus width,either 1-bit or 4-bit.So in order to meet our case,we need more flexible mechanism
To inform the upper commom driver to know our situation.

That's just iterating what's already been said. My claim is that 4-bit is 4-bit, regardless if it's MMC or SD. So if you want this patch to go in you need to explain why there is a difference for the blackfin controller.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#9 lore raw
Quoted 16 lines · Pierre Ossman
Quoted 12 lines · Cliff

Hi,all

I'd like to say something about this issue.
Currently,the blackfin on chip SD host ONLY support 1-bit MMC while support 1-bit/4-bit SD/SDIO.
And we want our driver to support both 1-bit MMC and 4-bit SD/SDIO.but the current MMC driver framework
Only allow us to set one kind of bus width,either 1-bit or 4-bit.So in order to meet our case,we need more flexible mechanism
To inform the upper commom driver to know our situation.

Quoted 2 lines

That's just iterating what's already been said. My claim is that 4-bit is 4-bit, regardless if it's MMC or SD. So if you want this patch to go in you need to explain why there is a difference for the blackfin controller.

Actually, Blackfin BF54x on-chip SDIO host controller is supposed to support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC works at 4-bit mode there will be a FIFO underrun error
(http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3535).
While SD works at 4-bit mode is OK. We believe this is a hardware issue of the SDIO host controller of BF54x.

We intend to workaround in our own BF54x SDIO host controller driver, but there is no place for us to determine MMC or SD. One choice is to hack common code like this:
----

drivers/mmc/core/mmc.c +4 -1
@@ -358,6 +358,9 @@
 	/*
 	 * Activate wide bus (if supported).
 	 */
+/*Currently,Blackfin 54x only support 1 bit MMC,while support 4 bit SD */
+/*So if card type is MMC don't enable 4 bit mode*/
+#if !defined(CONFIG_BF54x)
 	if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
 		(host->caps & MMC_CAP_4_BIT_DATA)) {
 		err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
@@ -367,7 +370,7 @@
 
 		mmc_set_bus_width(card->host, MMC_BUS_WIDTH_4);
 	}
-
+#endif
 	if (!oldcard)
 		host->card = card;
 

----

Another choice is to use Mike's patch to split the 4-bit mode into MMC-4-BIT and SD-4-BIT. So we can support 1-bit and 4-bit SD as well as 1-bit MMC.

Thanks
-Bryan Wu

#10 lore raw
Quoted 7 lines · On Thu, 10 Jan 2008 00:45:27 +0800 "Bryan Wu" <[email protected]> wrote:

Actually, Blackfin BF54x on-chip SDIO host controller is supposed to support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC works at 4-bit mode there will be a FIFO underrun error
(http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3535).
While SD works at 4-bit mode is OK. We believe this is a hardware issue of the SDIO host controller of BF54x.

Odd. As there shouldn't be a difference, I'm inclined to believe that this is card dependent. So it could as well appear with some SD cards as well.

How much have you tested this issue? That tracker entry isn't very verbose.

Also, how can an underrun appear? The system should have flow control. And an underrun does not sound like a bus problem, rather that you have a card with different speed characteristics than the hardware/driver can handle.

Quoted 4 lines

We intend to workaround in our own BF54x SDIO host controller driver, but there is no place for us to determine MMC or SD. One choice is to hack common code like this:

_If_ it truly cannot handle 4-bit MMC, then Mike's patch is the way to go. But I'm not yet convinced that the problem is related to MMC vs SD.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#11 lore raw
Quoted 4 lines · Pierre Ossman
Quoted 1 line · On Thu, 10 Jan 2008 00:45:27 +0800 "Bryan Wu" <[email protected]> wrote:
Quoted 9 lines
Quoted 6 lines

Actually, Blackfin BF54x on-chip SDIO host controller is supposed to support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC works at 4-bit mode there will be a FIFO underrun error
(http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3535).
While SD works at 4-bit mode is OK. We believe this is a hardware issue of the SDIO host controller of BF54x.

Odd. As there shouldn't be a difference, I'm inclined to believe that this is card dependent. So it could as well appear with some SD cards as well.

At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware Reference, there is a table which guide us the SDH controller does not support 4-bit mode MMC card. Please found the table picture in the attachment or get the document at:
http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf

Quoted 4 lines

How much have you tested this issue? That tracker entry isn't very verbose.

Also, how can an underrun appear? The system should have flow control. And an underrun does not sound like a bus problem, rather that you have a card with different speed characteristics than the hardware/driver can handle.

I am sorry for this mistake. This tracker is not for this 4-bit issue, it is another bug which should be fixed by Cliff.

Quoted 7 lines
Quoted 4 lines

We intend to workaround in our own BF54x SDIO host controller driver, but there is no place for us to determine MMC or SD. One choice is to hack common code like this:

_If_ it truly cannot handle 4-bit MMC, then Mike's patch is the way to go. But I'm not yet convinced that the problem is related to MMC vs SD.

Thanks, actually we are not yet convinced by our hardware designer why BF54x SDH does not support 4-bit MMC.

Quoted 9 lines

Rgds
--
-- Pierre Ossman

Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org

#12 lore raw
Quoted 7 lines · On Thu, 10 Jan 2008 17:22:55 +0800 "Bryan Wu" <[email protected]> wrote:

At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware Reference, there is a table which guide us the SDH controller does not support 4-bit mode MMC card. Please found the table picture in the attachment or get the document at:
http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf

Ok, but this just means the controller wasn't designed with 4-bit MMC in mind. As several other "SD-only" controller have been tested with modern MMC cards without a problem, this is not sufficient to explain any problem.

Quoted 4 lines

Thanks, actually we are not yet convinced by our hardware designer why BF54x SDH does not support 4-bit MMC.

Please keep me informed on how it progresses. I'd like an at least plausible explanation, preferably also some empirical data, before I'm ready to accept Mike's patch.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#13 lore raw
Quoted 4 lines · Pierre Ossman
Quoted 1 line · On Thu, 10 Jan 2008 17:22:55 +0800 "Bryan Wu" <[email protected]> wrote:
Quoted 9 lines
Quoted 6 lines

At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware Reference, there is a table which guide us the SDH controller does not support 4-bit mode MMC card. Please found the table picture in the attachment or get the document at:
http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf

Ok, but this just means the controller wasn't designed with 4-bit MMC in mind. As several other "SD-only" controller have been tested with modern MMC cards without a problem, this is not sufficient to explain any problem.

This should be some HW design issue and BF54x including SDH controller is in mass production.
There is no chance to change the silicon, we just wanna use software driver to workaround this issue.
So Mike's patch is here.

Quoted 7 lines
Quoted 4 lines

Thanks, actually we are not yet convinced by our hardware designer why BF54x SDH does not support 4-bit MMC.

Please keep me informed on how it progresses. I'd like an at least plausible explanation, preferably also some empirical data, before I'm ready to accept Mike's patch.

We were told this is an hardware design issue, so please help us to workaround it in software side with Mike's patch.
And how do you think my suggestion to Mike's patch,
#define MMC_CAP_4_BIT_DATA ( MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA) Then no need to change other MMC host drivers

Thanks
Regards,
-Bryan Wu

#14 lore raw
Quoted 26 lines · Bryan Wu
Quoted 4 lines · Pierre Ossman
Quoted 1 line · On Thu, 10 Jan 2008 17:22:55 +0800 "Bryan Wu" <[email protected]> wrote:
Quoted 9 lines
Quoted 6 lines

At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware Reference, there is a table which guide us the SDH controller does not support 4-bit mode MMC card. Please found the table picture in the attachment or get the document at:
http://www.analog.com/UploadedFiles/Associated_Docs/61460151169789ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference.pdf

Ok, but this just means the controller wasn't designed with 4-bit MMC in mind. As several other "SD-only" controller have been tested with modern MMC cards without a problem, this is not sufficient to explain any problem.

This should be some HW design issue and BF54x including SDH controller is in mass production.
There is no chance to change the silicon, we just wanna use software driver to workaround this issue.
So Mike's patch is here.

Quoted 5 lines
Quoted 4 lines

Thanks, actually we are not yet convinced by our hardware designer why BF54x SDH does not support 4-bit MMC.

Quoted 8 lines
Quoted 2 lines

Please keep me informed on how it progresses. I'd like an at least plausible explanation, preferably also some empirical data, before I'm ready to accept Mike's patch.

We were told this is an hardware design issue, so please help us to workaround it in software side with Mike's patch.
And how do you think my suggestion to Mike's patch,
#define MMC_CAP_4_BIT_DATA ( MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA) Then no need to change other MMC host drivers

i can send an updated patch as needed. i think Bryan's suggestion here is a good one.
-mike

#15 lore raw
In reply to Bryan Wu
Quoted 2 lines · On Fri, 11 Jan 2008 14:17:01 +0800 "Bryan Wu" <[email protected]> wrote:

We were told this is an hardware design issue, so please help us to workaround it in software side with Mike's patch.

I'm afraid that's insufficient motivation for this change. All documentation and real world tests say that MMC and SD 4-bit data is 100% compatible. So it's far more probable that you've misdiagnosed your error than this being the actual problem. The fact that 4-bit MMC support has been present for some time and you're only now seeing a problem further supports that.

In light of that, the suggested patch would not only be incorrect, it would also be worse than doing nothing. You would be papering over a symptom, making the real problem harder to find.

If you want something ready for upstream, for now I suggest removing MMC_CAP_4_BIT_DATA completely from your driver's caps field.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#16 lore raw
Quoted 5 lines · Pierre Ossman
Quoted 2 lines · Bryan Wu

We were told this is an hardware design issue, so please help us to workaround it in software side with Mike's patch.

So it's far more probable that you've misdiagnosed your error than this being the actual problem.

the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here.

Quoted 1 line

The fact that 4-bit MMC support has been present for some time and you're only now seeing a problem further supports that.

not in the least actually. we just started developing the driver. it has seen no real world use. we've been testing things internally to make sure the setup is sane. 4-bit MMC is coming up as not working. -mike

#17 lore raw
Quoted 6 lines · On Fri, 11 Jan 2008 04:08:53 -0500 "Mike Frysinger" <[email protected]>…
Quoted 1 line · Pierre Ossman

So it's far more probable that you've misdiagnosed your error than this being the actual problem.

the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here.

More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out. You haven't even described how it fails, just that it does. No information about what cards you've tested and how you've tested them to confirm that your theory on 4-bit data is accurate.

You have no track record with me, and you're proposing something that goes against all known information. So you have to understand that I'm sceptical about your claims. I won't dismiss them off hand, but I need to be convinced you haven't made a mistake when coming to this conclusion.

Quoted 5 lines
Quoted 1 line

The fact that 4-bit MMC support has been present for some time and you're only now seeing a problem further supports that.

not in the least actually. we just started developing the driver. it has seen no real world use. we've been testing things internally to make sure the setup is sane. 4-bit MMC is coming up as not working.

Fair enough. But if it's a new driver that hasn't seen real-world testing, then there might be other bugs influencing things.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#18 lore raw
Quoted 8 lines · Pierre Ossman
Quoted 5 lines · Mike Frysinger
Quoted 1 line · Pierre Ossman

So it's far more probable that you've misdiagnosed your error than this being the actual problem.

the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here.

More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out. You haven't even described how it fails, just that it does. No information about what cards you've tested and how you've tested them to confirm that your theory on 4-bit data is accurate.

unfortunately, i cant fill these gaps myself directly. all i bring to the table is proper integration with the common frameworks. i'm relying on the guys developing the drivers and the guys who actually designed the hardware for information. they tell me it doesnt work, i just believe them ;).

Cliff should be able to enumerate the cards he has tested and the issues he's run into. i'll see if i cant get more in depth information from the hardware guys beyond the documentation on the sdh already available in the hardware manual (which i'm guessing has not been enough to appease you).

Quoted 1 line

You have no track record with me, and you're proposing something that goes against all known information. So you have to understand that I'm sceptical about your claims. I won't dismiss them off hand, but I need to be convinced you haven't made a mistake when coming to this conclusion.

that's fair. i could actually be a gnome sitting outside in your lawn. you have no idea.
-mike

#19 lore raw
Quoted 6 lines · On Fri, 11 Jan 2008 04:47:44 -0500 "Mike Frysinger" <[email protected]>…

Cliff should be able to enumerate the cards he has tested and the issues he's run into. i'll see if i cant get more in depth information from the hardware guys beyond the documentation on the sdh already available in the hardware manual (which i'm guessing has not been enough to appease you).

Great. And you're right in that the spec did not give any indication that MMC shouldn't work.

I did notice one thing though. The pull-ups and pull-downs seem to be controllable. If I remember correctly, DAT3 needs to have a controller-side pull-up for MMC cards. And the docs said the default was not to provide that (in order to use the internal pull-up that most, but not all, SD cards have for detection). Might be something to look at if you haven't already.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#20 lore raw
Quoted 12 lines · Pierre Ossman
Quoted 6 lines · On Fri, 11 Jan 2008 04:47:44 -0500 "Mike Frysinger" <[email protected]>…

Cliff should be able to enumerate the cards he has tested and the issues he's run into. i'll see if i cant get more in depth information from the hardware guys beyond the documentation on the sdh already available in the hardware manual (which i'm guessing has not been enough to appease you).

Great. And you're right in that the spec did not give any indication that MMC shouldn't work.

Our tester will reopen a tracker of this issue. When it's fired, you will be updated with this information.

Quoted 2 lines

I did notice one thing though. The pull-ups and pull-downs seem to be controllable. If I remember correctly, DAT3 needs to have a controller-side pull-up for MMC cards. And the docs said the default was not to provide that (in order to use the internal pull-up that most, but not all, SD cards have for detection). Might be something to look at if you haven't already.

I guess it is for MMC/SD card insert detection. Is it related with the 4-bit MMC and 4-bit SD?
Actually, there are some issues about the card insert detection on BF54x SDH. Following is some comments of our bfin-sdh driver which is in the development.

---
/* In term of ADSP_BF54x_Blackfin_Processor_Peripheral_Hardware_Reference,
* the SDH allows software to detect a card when it is inserted into its slot.
* The SD_DATA3 pin powers up low due to a special pull-down resistor. When an
* SD Card is inserted in its slot, the resistance increases and a rising edge
* is detected by the SDH module.
* But this doesn't work sometimes. When a MMC/SD card is inserted, the voltage
* doesn't rise on SD_DATA3. In term of The MultiMediaCard System Specification,
* SD_DATA3 is used as CS pin in SPI mode. The MultiMediaCard wakes up in the
* MultiMediaCard mode. During the scan procedure, host will send CMD0 to reset
* MMC card, if CS pin is low, MMC card will enter SPI mode. Of course Secure
* Digital Host controller is not a SPI controller. So the Card detect function
* has to be disabled. After card is inserted run "echo 0 > /proc/driver/sdh"
* to trigger card scanning */
---

Thanks
-Bryan Wu

#21 lore raw
Quoted 7 lines · On Fri, 11 Jan 2008 18:22:14 +0800 "Bryan Wu" <[email protected]> wrote:

I guess it is for MMC/SD card insert detection. Is it related with the 4-bit MMC and 4-bit SD?
Actually, there are some issues about the card insert detection on BF54x SDH. Following is some comments of our bfin-sdh driver which is in the development.

Right. As you've noticed, that pin is not a reliable way of detecting cards. It works badly, if all, for MMC cards. And some SD cards also lack the necessary pull-up.

But for the matter at hand, some cards might rely on the pull-up being there, so you'll get bit-errors without it. I don't have time to double check the specs right now, but it might explain why you're seeing problems with MMC and not SD.

Btw, the MMC core sends you ios information on how you should fiddle with that bit. It was needed on a Winbond controller (the wbsd driver) as some models relied on it for card detection.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#22 lore raw
In reply to Pierre Ossman

On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:

Quoted 5 lines
Quoted 2 lines · On Fri, 11 Jan 2008 04:08:53 -0500 "Mike Frysinger" <[email protected]>…
Quoted 1 line · Pierre Ossman

So it's far more probable that you've misdiagnosed your error than

Quoted 8 lines

this being the actual problem.

Quoted 4 lines

the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here.

More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out.

I have been trying to get the detailed information from the hardware (silicon designer) guy about why he believes support for 4-bit MMC is not there, but I have not heard back yet.

As soon as I hear from them - and either understand why 4-bit MMC doesn't work, or if the Blackfin docs are incorrect (either is OK outcome) - I will let you know.

Thanks
-Robin

#23 lore raw

On Fri 11 Jan 2008 12:52, Robin Getz pondered:

Quoted 15 lines

On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:

Quoted 5 lines
Quoted 2 lines · On Fri, 11 Jan 2008 04:08:53 -0500 "Mike Frysinger" <[email protected]>…
Quoted 1 line · Pierre Ossman

So it's far more probable that you've misdiagnosed your error than

Quoted 8 lines

this being the actual problem.

Quoted 4 lines

the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here.

More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out.

Quoted 7 lines

I have been trying to get the detailed information from the hardware (silicon designer) guy about why he believes support for 4-bit MMC is not there, but I have not heard back yet.

As soon as I hear from them - and either understand why 4-bit MMC doesn't work, or if the Blackfin docs are incorrect (either is OK outcome) - I will let you know.

According to the HW folks - it is exactly as Pierre indicated - in theory it should work, 4-bit MMC requires usage of different set of commands as compared to 4-bit SD, so it should be just software - although no one has tested it yet.

So I guess this is back on Bryan/Cliff to make work....

Thanks for pushing back.

-Robin

#24 lore raw
Quoted 21 lines · Robin Getz

On Fri 11 Jan 2008 12:52, Robin Getz pondered:

Quoted 19 lines

On Fri 11 Jan 2008 04:35, Pierre Ossman pondered:

Quoted 5 lines
Quoted 2 lines · On Fri, 11 Jan 2008 04:08:53 -0500 "Mike Frysinger" <[email protected]>…
Quoted 1 line · Pierre Ossman

So it's far more probable that you've misdiagnosed your error than

Quoted 8 lines

this being the actual problem.

Quoted 4 lines

the guys who design the silicon are telling us it doesnt work. our tests show it not working. i'm not sure what else you want here.

More information. You have not provided any speculation as to why it doesn't work, or what you've done to figure it out.

I have been trying to get the detailed information from the hardware (silicon designer) guy about why he believes support for 4-bit MMC is not there, but I have not heard back yet.

Quoted 9 lines
Quoted 3 lines

As soon as I hear from them - and either understand why 4-bit MMC doesn't work, or if the Blackfin docs are incorrect (either is OK outcome) - I will let you know.

According to the HW folks - it is exactly as Pierre indicated - in theory it should work, 4-bit MMC requires usage of different set of commands as compared to 4-bit SD, so it should be just software - although no one has tested it yet.

Vivi is helping us to do the test again, and she will fire a bug tracker about this issue next week.
So we can debug it again.

Quoted 4 lines

So I guess this is back on Bryan/Cliff to make work....

Thanks for pushing back.

Yes, Thanks a lot Pierre.
-Bryan Wu

#25 lore raw
In reply to Robin Getz
Quoted 10 lines · On Sat, 12 Jan 2008 08:02:37 -0500 Robin Getz <[email protected]>…

According to the HW folks - it is exactly as Pierre indicated - in theory it should work, 4-bit MMC requires usage of different set of commands as compared to 4-bit SD, so it should be just software - although no one has tested it yet.

So I guess this is back on Bryan/Cliff to make work....

Thanks for pushing back.

It's what I do ;)

If you provide some dumps of your test runs next week, I'm sure I can help with some qualified guesses as to what the problem might be.

Rgds

Signature · 5 lines
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
#26 lore raw
In reply to Mike Frysinger
Quoted 149 lines · Mike Frysinger

The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current convention of MMC_CAP_4_BIT_DATA meaning "your host controller can do 1-bit or 4-bit for all modes" is insufficient for our needs. The attached patch splits MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and MMC_CAP_SD_4_BIT_DATA and updates all host controllers to include these in their caps and then changes existing code to check the new defines. At the moment, SD/SDIO are lumped into MMC_CAP_SD_4_BIT_DATA ... should I bother with splitting that into SD and SDIO as well while I'm doing this ?

---

drivers/mmc/core/mmc.c +1 -1
index 68c0e3b..ca12db7 100644
@@ -397,7 +397,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
         * Activate wide bus (if supported).
         */
        if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
-               (host->caps & MMC_CAP_4_BIT_DATA)) {
+               (host->caps & MMC_CAP_MMC_4_BIT_DATA)) {
                err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
                        EXT_CSD_BUS_WIDTH, EXT_CSD_BUS_WIDTH_4);
                if (err)
drivers/mmc/core/sd.c +1 -1
index d1c1e0f..974b63d 100644
@@ -441,7 +441,7 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
        /*
         * Switch to wider bus (if supported).
         */
-       if ((host->caps & MMC_CAP_4_BIT_DATA) &&
+       if ((host->caps & MMC_CAP_SD_4_BIT_DATA) &&
                (card->scr.bus_widths & SD_SCR_BUS_WIDTH_4)) {
                err = mmc_app_set_bus_width(card, MMC_BUS_WIDTH_4);
                if (err)
drivers/mmc/core/sdio.c +1 -1
index 87a50f4..1d389c8 100644
@@ -143,7 +143,7 @@ static int sdio_enable_wide(struct mmc_card *card)
        int ret;
        u8 ctrl;
 
-       if (!(card->host->caps & MMC_CAP_4_BIT_DATA))
+       if (!(card->host->caps & MMC_CAP_SD_4_BIT_DATA))
                return 0;
 
        if (card->cccr.low_speed && !card->cccr.wide_bus)
drivers/mmc/host/at91_mci.c +1 -1
index b1edcef..63d89b0 100644
@@ -851,7 +851,7 @@ static int __init at91_mci_probe(struct platform_device *pdev)
        host->board = pdev->dev.platform_data;
        if (host->board->wire4) {
                if (cpu_is_at91sam9260() || cpu_is_at91sam9263())
-                       mmc->caps |= MMC_CAP_4_BIT_DATA;
+                       mmc->caps |= (MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA);
                else
                        printk("AT91 MMC: 4 wire bus mode not supported"
                                " - using 1 wire\n");
drivers/mmc/host/imxmmc.c +1 -1
index f2070a1..67d4bc0 100644
@@ -975,7 +975,7 @@ static int imxmci_probe(struct platform_device *pdev)
        mmc->f_min = 150000;
        mmc->f_max = CLK_RATE/2;
        mmc->ocr_avail = MMC_VDD_32_33;
-       mmc->caps = MMC_CAP_4_BIT_DATA;
+       mmc->caps = (MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA);
 
        /* MMC core transfer sizes tunable parameters */
        mmc->max_hw_segs = 64;
drivers/mmc/host/omap.c +1 -1
index 971e18b..b1ae793 100644
@@ -1079,7 +1079,7 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
        mmc->caps = MMC_CAP_MULTIWRITE | MMC_CAP_BYTEBLOCK;
 
        if (minfo->wire4)
-                mmc->caps |= MMC_CAP_4_BIT_DATA;
+                mmc->caps |= (MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA);
 
        /* Use scatterlist DMA to reduce per-transfer costs.
         * NOTE max_seg_size assumption that small blocks aren't
drivers/mmc/host/pxamci.c +1 -1
index 1654a33..4fa00f1 100644
@@ -527,7 +527,7 @@ static int pxamci_probe(struct platform_device *pdev)
        mmc->caps = 0;
        host->cmdat = 0;
        if (!cpu_is_pxa21x() && !cpu_is_pxa25x()) {
-               mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
+               mmc->caps |= MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
                host->cmdat |= CMDAT_SDIO_INT_EN;
        }
 
drivers/mmc/host/sdhci.c +1 -1
index 785bbdc..09c4358 100644
@@ -1405,7 +1405,7 @@ static int __devinit sdhci_probe_slot(struct pci_dev *pdev, int slot)
        mmc->ops = &sdhci_ops;
        mmc->f_min = host->max_clk / 256;
        mmc->f_max = host->max_clk;
-       mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MULTIWRITE | MMC_CAP_SDIO_IRQ;
+       mmc->caps = MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_MULTIWRITE | MMC_CAP_SDIO_IRQ;
 
        if (caps & SDHCI_CAN_DO_HISPD)
                mmc->caps |= MMC_CAP_SD_HIGHSPEED;
drivers/mmc/host/tifm_sd.c +1 -1
index 20d5c7b..78cad6b 100644
@@ -973,7 +973,7 @@ static int tifm_sd_probe(struct tifm_dev *sock)
 
        mmc->ops = &tifm_sd_ops;
        mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
-       mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MULTIWRITE;
+       mmc->caps = MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_MULTIWRITE;
        mmc->f_min = 20000000 / 60;
        mmc->f_max = 24000000;
 
drivers/mmc/host/wbsd.c +1 -1
index 4d5f374..70d6071 100644
@@ -1219,7 +1219,7 @@ static int __devinit wbsd_alloc_mmc(struct device *dev)
        mmc->f_min = 375000;
        mmc->f_max = 24000000;
        mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
-       mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_MULTIWRITE;
+       mmc->caps = MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA | MMC_CAP_MULTIWRITE;
 
        spin_lock_init(&host->lock);
 
include/linux/mmc/host.h +0 -0
index 7ab962f..142fa69 100644
@@ -88,12 +88,13 @@ struct mmc_host {
 
        unsigned long           caps;           /* Host capabilities */

include/linux/mmc/host.h struct mmc_host { · line 98

Quoted 10 lines
include/linux/mmc/host.h +2 -1
 
-#define MMC_CAP_4_BIT_DATA     (1 << 0)        /* Can the host do 4 bit transfers */
+#define MMC_CAP_SD_4_BIT_DATA  (1 << 0)        /* Can the host do SD 4 bit transfers */
 #define MMC_CAP_MULTIWRITE     (1 << 1)        /* Can accurately report bytes sent to card on error */
 #define MMC_CAP_MMC_HIGHSPEED  (1 << 2)        /* Can do MMC high-speed timing */
 #define MMC_CAP_SD_HIGHSPEED   (1 << 3)        /* Can do SD high-speed timing */
 #define MMC_CAP_SDIO_IRQ       (1 << 4)        /* Can signal pending SDIO IRQs */
 #define MMC_CAP_SPI            (1 << 5)        /* Talks only SPI protocols */
+#define MMC_CAP_MMC_4_BIT_DATA (1 << 6)        /* Can the host do MMC 4 bit transfers */
 

One suggestion:

#define MMC_CAP_4_BIT_DATA ( MMC_CAP_SD_4_BIT_DATA | MMC_CAP_MMC_4_BIT_DATA)

Then no need to change all MMC host drivers, like
drivers/mmc/host/wbsd.c

-Bryan Wu