[PATCH 2.6.19] mmc: Add support for SDHC cards (Take 2)

Previous thread: Re: [PATCH 2.6.19] mmc: Add support for SDHC cards by Philip Langdale on Monday, January 1, 2007 - 11:20 am. (3 messages)

Next thread: Re: [PATCH] Documentation: Explain a second alternative for multi-line macros. by Jan Engelhardt on Monday, January 1, 2007 - 11:37 am. (4 messages)
To: <linux-kernel@...>
Cc: Andrew Morton <akpm@...>, Johannes Berg <johannes@...>, <video4linux-list@...>, David Woodhouse <dwmw2@...>, <linux-ppp@...>, <dm-devel@...>
Date: Wednesday, December 31, 1969 - 8:00 pm

From: Johannes Berg <johannes@sipsolutions.net>

Straight forward conversions to CONFIG_MODULE; many drivers
include <linux/kmod.h> conditionally and then don't have any
other conditional code so remove it from those.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: video4linux-list@redhat.com
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-ppp@vger.kernel.org
Cc: dm-devel@redhat.com
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/md/md.c | 7 -------
drivers/media/video/cpia.c | 4 ----
drivers/media/video/usbvision/usbvision-core.c | 4 ----
drivers/media/video/usbvision/usbvision-video.c | 4 ----
drivers/media/video/v4l1-compat.c | 4 ----
drivers/media/video/v4l2-common.c | 4 ----
drivers/media/video/vino.c | 5 +----
drivers/media/video/w9968cf.c | 4 ++--
drivers/mtd/mtdpart.c | 2 --
drivers/net/irda/sir_dongle.c | 2 --
drivers/net/ppp_generic.c | 10 +++-------
drivers/net/pppox.c | 9 ++-------
drivers/video/fbmem.c | 17 ++---------------
13 files changed, 10 insertions(+), 66 deletions(-)

diff -r 6251a9fdf8f9 drivers/md/md.c
--- a/drivers/md/md.c Mon Aug 25 14:22:06 2008 +1000
+++ b/drivers/md/md.c Mon Aug 25 14:27:32 2008 +1000
@@ -44,14 +44,9 @@
#include <linux/mutex.h>
#include <linux/ctype.h>
#include <linux/freezer.h>
-
#include <linux/init.h>
-
#include <linux/file.h>
-
-#ifdef CONFIG_KMOD
#include <linux/kmod.h>
-#endif

#include <asm/unaligned.h>

@@ -3558,12 +3553,10 @@ static int do_md_run(mddev_t * mddev)
}
}

-#ifdef CONFIG_KMOD
if (mddev->level != LEVEL_NONE)
request_module("md-level-%d", mddev->level);
else if (mddev->clevel...

To: Pierre Ossman <drzeus-list@...>, <linux-kernel@...>
Cc: John Gilmore <gnu@...>
Date: Monday, January 1, 2007 - 11:29 am

Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:

i) Add a card flag indicating the card uses block level addressing and check
it in the block driver. As we never took advantage of byte-level addressing,
this simply involves skipping the block -> byte translation when sending commands.

ii) The layout of the CSD is changed - a set of fields are discarded to make space
for a larger C_SIZE. We did not reference any of the discarded fields except those
related to the C_SIZE.

iii) Read and write timeouts are fixed values and not calculated from CSD values.

iv) Before invoking SEND_APP_OP_COND, we must invoke the new SEND_IF_COND to inform
the card we support SDHC.

I've done some basic read and write tests and everything seems to work fine but one
should obviously use caution in case it eats your data.

Signed-off-by: Philipl Langdale <philipl@overt.org>
---
drivers/mmc/mmc.c | 115 ++++++++++++++++++++++++++++++++-----------
drivers/mmc/mmc_block.c | 8 ++
include/linux/mmc/card.h | 3 +
include/linux/mmc/mmc.h | 3 -
include/linux/mmc/protocol.h | 13 ++++
5 files changed, 112 insertions(+), 30 deletions(-)

--- /usr/src/linux/drivers/mmc/mmc.c 2007-01-01 07:12:02.000000000 -0800
+++ linux-2.6.19-sdhc/drivers/mmc/mmc.c 2007-01-01 06:41:01.000000000 -0800
@@ -289,7 +289,10 @@
else
limit_us = 100000;

- if (timeout_us > limit_us) {
+ /*
+ * SDHC cards always use these fixed values.
+ */
+ if (timeout_us > limit_us || mmc_card_blockaddr(card)) {
data->timeout_ns = limit_us * 1000;
data->timeout_clks = 0;
}
@@ -588,34 +591,65 @@

if (mmc_card_sd(card)) {
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 0) {
+
+ switch (csd_struct) {
+ case 0:
+ m = UNSTUFF_BITS(resp, 115, 4);
...

To: Philip Langdale <philipl@...>
Cc: Pierre Ossman <drzeus-list@...>, <linux-kernel@...>, John Gilmore <gnu@...>
Date: Wednesday, January 3, 2007 - 7:06 pm

On Mon, 01 Jan 2007 07:29:55 -0800

This gives MMC_RSP_R1 and MMC_RSP_R6 the same value, so

drivers/mmc/tifm_sd.c: In function 'tifm_sd_op_flags':
drivers/mmc/tifm_sd.c:190: error: duplicate case value
drivers/mmc/tifm_sd.c:181: error: previously used here
-

To: Pierre Ossman <drzeus-list@...>, Alex Dubov <oakad@...>
Cc: Andrew Morton <akpm@...>, <linux-kernel@...>
Date: Thursday, January 4, 2007 - 1:24 am

This is a bug. The MMC_RSP_R? #defines do not fully characterise the
responses (specically, the way that the response is parsed is not
characterised) and consequently there is no guarantee of uniqueness.
Given this reality - the way that the tifm_sd driver works is unsafe.

If R6 had not been incorrectly defined (the missing RSP_OPCODE should
always have been there), then this code would not have worked. As things
currently stand, it is necessary to also check the command number to
decide on the correct response type - that's suboptimal and it's probably
good to uniquely identify the response in the mmc_command in some other
fashion.

I'm going to remove the R6 fix from my next diff to keep these things
distinct but this needs to be resolved.

--phil
-

To: Philip Langdale <philipl@...>, Pierre Ossman <drzeus-list@...>
Cc: Andrew Morton <akpm@...>, <linux-kernel@...>
Date: Thursday, January 4, 2007 - 8:50 am

I think the trivial fix will do (after all, there's nothing that should matter to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I can't test this.

--- tifm_sd.c.orig 2006-12-11 01:39:28.000000000 +1100
+++ tifm_sd.c 2007-01-04 23:40:48.441724000 +1100
@@ -179,6 +179,8 @@
case MMC_RSP_R1B:
rc |= TIFM_MMCSD_RSP_BUSY; // deliberate fall-through
case MMC_RSP_R1:
+ case MMC_RSP_R6:
+ case MMC_RSP_R7:
rc |= TIFM_MMCSD_RSP_R1;
break;
case MMC_RSP_R2:
@@ -187,9 +189,6 @@
case MMC_RSP_R3:
rc |= TIFM_MMCSD_RSP_R3;
break;
- case MMC_RSP_R6:
- rc |= TIFM_MMCSD_RSP_R6;
- break;
default:
BUG();
}

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-

To: Philip Langdale <philipl@...>
Cc: Alex Dubov <oakad@...>, Andrew Morton <akpm@...>, <linux-kernel@...>
Date: Thursday, January 4, 2007 - 1:59 am

Amen to that. All hw vendors that implement this particular form of
brain damage should be dragged out and shot.

I'll fix a patch for this later on.

Rgds

--
-- Pierre Ossman

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

-

To: Pierre Ossman <drzeus-list@...>
Cc: Alex Dubov <oakad@...>, Andrew Morton <akpm@...>, <linux-kernel@...>
Date: Thursday, January 4, 2007 - 2:35 am

See my updated Take 3 patch. I've implemented a uniqueness fix by
adding additional RSP flags do make R6 and R7 unique. I don't know
if this is what you wanted, but it works without being too ugly.

However, also note my caveat that it's not clear if tifm or imxmmc
can ever be made to work with SD 2.0 cards. *sigh*

--phil
-

To: Philip Langdale <philipl@...>
Cc: Alex Dubov <oakad@...>, Andrew Morton <akpm@...>, <linux-kernel@...>
Date: Thursday, January 4, 2007 - 3:32 am

NAK. If two response types look the same over the wire, then they should
have the same definition. Hardware that uses type codes is simply

They probably can. They just need a fix for their switch statements.

Rgds

--
-- Pierre Ossman

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

-

To: Philip Langdale <philipl@...>
Cc: <linux-kernel@...>, John Gilmore <gnu@...>
Date: Wednesday, January 3, 2007 - 5:06 pm

Nah... I think a mmc_send_if_cond() would be cleaner. The setup routine
should contain the sequence of events needed, while we abstract the
really low level grunt work into functions.

(more on that subject as soon as kernel.org has finished mirroring ;))

Rgds

--
-- Pierre Ossman

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

-

Previous thread: Re: [PATCH 2.6.19] mmc: Add support for SDHC cards by Philip Langdale on Monday, January 1, 2007 - 11:20 am. (3 messages)

Next thread: Re: [PATCH] Documentation: Explain a second alternative for multi-line macros. by Jan Engelhardt on Monday, January 1, 2007 - 11:37 am. (4 messages)