[PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Wolfgang Mües]

From: Wolfgang Muees <wolfgang.mues@auerswald.de>

o A very large subset of SD cards in the market send their
  responses and data non-byte-aligned. So add logic to the
  mmc spi driver to handle this mess.

Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>

---
This is one of a line of patches to enhance the usability of
the mmc spi host port driver from "don't work with most SD cards"
to "work with nearly all SD cards" (including those ugly cards
with non-byte-aligned responses).

diff -uprN 2_6_29_rc7_patch6_jiffies_and_scheduling/drivers/mmc/host/mmc_spi.c 2_6_29_rc7_patch7_unaligned_responses/drivers/mmc/host/mmc_spi.c
--- 2_6_29_rc7_patch6_jiffies_and_scheduling/drivers/mmc/host/mmc_spi.c	2009-03-11 13:49:53.000000000 +0100
+++ 2_6_29_rc7_patch7_unaligned_responses/drivers/mmc/host/mmc_spi.c	2009-03-11 13:51:25.000000000 +0100
@@ -254,6 +254,10 @@ static int mmc_spi_response_get(struct m
 	u8	*cp = host->data->status;
 	u8	*end = cp + host->t.len;
 	int	value = 0;
+	int	bitshift;
+	u8 	leftover = 0;
+	unsigned short rotator;
+	int 	i;
 	char	tag[32];
 
 	snprintf(tag, sizeof(tag), "  ... CMD%d response SPI_%s",
@@ -271,9 +275,8 @@ static int mmc_spi_response_get(struct m
 
 	/* Data block reads (R1 response types) may need more data... */
 	if (cp == end) {
-		unsigned	i;
-
 		cp = host->data->status;
+		end = cp+1;
 
 		/* Card sends N(CR) (== 1..8) bytes of all-ones then one
 		 * status byte ... and we already scanned 2 bytes.
@@ -298,20 +301,34 @@ static int mmc_spi_response_get(struct m
 	}
 
 checkstatus:
-	if (*cp & 0x80) {
-		dev_dbg(&host->spi->dev, "%s: INVALID RESPONSE, %02x\n",
-					tag, *cp);
-		value = -EBADR;
-		goto done;
+	bitshift = 0;
+	if (*cp & 0x80)	{
+		/* Houston, we have an ugly card with a bit-shifted response */
+		rotator = *cp++ << 8;
+		/* read the next byte */
+		if (cp == end) {
+			value = mmc_spi_readbytes(host, 1);
+			if (value < 0)
+				goto done;
+			cp = host->data->status;
+			end = cp+1;
+		}
+		rotator |= *cp++;
+		while (rotator & 0x8000) {
+			bitshift++;
+			rotator <<= 1;
+		}
+		cmd->resp[0] = rotator >> 8;
+		leftover = rotator;
+	} else {
+		cmd->resp[0] = *cp++;
 	}
-
-	cmd->resp[0] = *cp++;
 	cmd->error = 0;
 
 	/* Status byte: the entire seven-bit R1 response.  */
 	if (cmd->resp[0] != 0) {
 		if ((R1_SPI_PARAMETER | R1_SPI_ADDRESS
-					| R1_SPI_ILLEGAL_COMMAND)
+				      | R1_SPI_ILLEGAL_COMMAND)
 				& cmd->resp[0])
 			value = -EINVAL;
 		else if (R1_SPI_COM_CRC & cmd->resp[0])
@@ -339,12 +356,45 @@ checkstatus:
 	 * SPI R5 == R1 + data byte; IO_RW_DIRECT
 	 */
 	case MMC_RSP_SPI_R2:
-		cmd->resp[0] |= *cp << 8;
+		/* read the next byte */
+		if (cp == end) {
+			value = mmc_spi_readbytes(host, 1);
+			if (value < 0)
+				goto done;
+			cp = host->data->status;
+			end = cp+1;
+		}
+		if (bitshift) {
+			rotator = leftover << 8;
+			rotator |= *cp << bitshift;
+			cmd->resp[0] |= (rotator & 0xFF00);
+		} else {
+			cmd->resp[0] |= *cp << 8;
+		}
 		break;
 
 	/* SPI R3, R4, or R7 == R1 + 4 bytes */
 	case MMC_RSP_SPI_R3:
-		cmd->resp[1] = get_unaligned_be32(cp);
+		rotator = leftover << 8;
+		cmd->resp[1] = 0;
+		for (i = 0; i < 4; i++) {
+			cmd->resp[1] <<= 8;
+			/* read the next byte */
+			if (cp == end) {
+				value = mmc_spi_readbytes(host, 1);
+				if (value < 0)
+					goto done;
+				cp = host->data->status;
+				end = cp+1;
+			}
+			if (bitshift) {
+				rotator |= *cp++ << bitshift;
+				cmd->resp[1] |= (rotator >> 8);
+				rotator <<= 8;
+			} else {
+				cmd->resp[1] |= *cp++;
+			}
+		}
 		break;
 
 	/* SPI R1 == just one status byte */
@@ -720,6 +770,8 @@ mmc_spi_readblock(struct mmc_spi_host *h
 	struct spi_device	*spi = host->spi;
 	int			status;
 	struct scratch		*scratch = host->data;
+	unsigned int 		bitshift;
+	u8			leftover;
 
 	/* At least one SD card sends an all-zeroes byte when N(CX)
 	 * applies, before the all-ones bytes ... just cope with that.
@@ -731,38 +783,60 @@ mmc_spi_readblock(struct mmc_spi_host *h
 	if (status == 0xff || status == 0)
 		status = mmc_spi_readtoken(host, timeout);
 
-	if (status == SPI_TOKEN_SINGLE) {
-		if (host->dma_dev) {
-			dma_sync_single_for_device(host->dma_dev,
-					host->data_dma, sizeof(*scratch),
-					DMA_BIDIRECTIONAL);
-			dma_sync_single_for_device(host->dma_dev,
-					t->rx_dma, t->len,
-					DMA_FROM_DEVICE);
-		}
+	if (status < 0) {
+		dev_dbg(&spi->dev, "read error %02x (%d)\n", status, status);
+		return status;
+	}
 
-		status = spi_sync(spi, &host->m);
+	/* The token may be bit-shifted...
+	 * the first 0-bit precedes the data stream.
+	 */
+	bitshift = 7;
+	while (status & 0x80) {
+		status <<= 1;
+		bitshift--;
+	}
+	leftover = status << 1;
 
-		if (host->dma_dev) {
-			dma_sync_single_for_cpu(host->dma_dev,
-					host->data_dma, sizeof(*scratch),
-					DMA_BIDIRECTIONAL);
-			dma_sync_single_for_cpu(host->dma_dev,
-					t->rx_dma, t->len,
-					DMA_FROM_DEVICE);
-		}
+	if (host->dma_dev) {
+		dma_sync_single_for_device(host->dma_dev,
+				host->data_dma, sizeof(*scratch),
+				DMA_BIDIRECTIONAL);
+		dma_sync_single_for_device(host->dma_dev,
+				t->rx_dma, t->len,
+				DMA_FROM_DEVICE);
+	}
 
-	} else {
-		dev_dbg(&spi->dev, "read error %02x (%d)\n", status, status);
+	status = spi_sync(spi, &host->m);
 
-		/* we've read extra garbage, timed out, etc */
-		if (status < 0)
-			return status;
+	if (host->dma_dev) {
+		dma_sync_single_for_cpu(host->dma_dev,
+				host->data_dma, sizeof(*scratch),
+				DMA_BIDIRECTIONAL);
+		dma_sync_single_for_cpu(host->dma_dev,
+				t->rx_dma, t->len,
+				DMA_FROM_DEVICE);
+	}
 
-		/* low four bits are an R2 subset, fifth seems to be
-		 * vendor specific ... map them all to generic error..
+	if (bitshift) {
+		/* Walk through the data and the crc and do
+		 * all the magic to get byte-aligned data.
 		 */
-		return -EIO;
+		u8 *cp = t->rx_buf;
+		unsigned int len;
+		unsigned int bitright = 8 - bitshift;
+		u8 temp;
+		for (len = t->len; len; len--) {
+			temp = *cp;
+			*cp++ = leftover | (temp >> bitshift);
+			leftover = temp << bitright;
+		}
+		cp = (u8 *) &scratch->crc_val;
+		temp = *cp;
+		*cp++ = leftover | (temp >> bitshift);
+		leftover = temp << bitright;
+		temp = *cp;
+		*cp = leftover | (temp >> bitshift);
 	}
 
 	/* Omitt the CRC check for CID and CSD reads. There are some SDHC

---
regards

i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@Auerswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Will Newton]

On Wed, Mar 11, 2009 at 1:40 PM, Wolfgang Mües
<wolfgang.mues@auerswald.de> wrote:
> From: Wolfgang Muees <wolfgang.mues@auerswald.de>
>
> o A very large subset of SD cards in the market send their
>  responses and data non-byte-aligned. So add logic to the
>  mmc spi driver to handle this mess.

Are you sure about this? Do you have any further references for this
or examples of cards that exhibit this problem?

Are you sure your SPI host controller is operating correctly?

> Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
>
> ---
> This is one of a line of patches to enhance the usability of
> the mmc spi host port driver from "don't work with most SD cards"
> to "work with nearly all SD cards" (including those ugly cards
> with non-byte-aligned responses).
>
> diff -uprN 2_6_29_rc7_patch6_jiffies_and_scheduling/drivers/mmc/host/mmc_spi.c 2_6_29_rc7_patch7_unaligned_responses/drivers/mmc/host/mmc_spi.c
> --- 2_6_29_rc7_patch6_jiffies_and_scheduling/drivers/mmc/host/mmc_spi.c 2009-03-11 13:49:53.000000000 +0100
> +++ 2_6_29_rc7_patch7_unaligned_responses/drivers/mmc/host/mmc_spi.c    2009-03-11 13:51:25.000000000 +0100
> @@ -254,6 +254,10 @@ static int mmc_spi_response_get(struct m
>        u8      *cp = host->data->status;
>        u8      *end = cp + host->t.len;
>        int     value = 0;
> +       int     bitshift;
> +       u8      leftover = 0;
> +       unsigned short rotator;
> +       int     i;
>        char    tag[32];
>
>        snprintf(tag, sizeof(tag), "  ... CMD%d response SPI_%s",
> @@ -271,9 +275,8 @@ static int mmc_spi_response_get(struct m
>
>        /* Data block reads (R1 response types) may need more data... */
>        if (cp == end) {
> -               unsigned        i;
> -
>                cp = host->data->status;
> +               end = cp+1;
>
>                /* Card sends N(CR) (== 1..8) bytes of all-ones then one
>                 * status byte ... and we already scanned 2 bytes.
> @@ -298,20 +301,34 @@ static int mmc_spi_response_get(struct m
>        }
>
>  checkstatus:
> -       if (*cp & 0x80) {
> -               dev_dbg(&host->spi->dev, "%s: INVALID RESPONSE, %02x\n",
> -                                       tag, *cp);
> -               value = -EBADR;
> -               goto done;
> +       bitshift = 0;
> +       if (*cp & 0x80) {
> +               /* Houston, we have an ugly card with a bit-shifted response */
> +               rotator = *cp++ << 8;
> +               /* read the next byte */
> +               if (cp == end) {
> +                       value = mmc_spi_readbytes(host, 1);
> +                       if (value < 0)
> +                               goto done;
> +                       cp = host->data->status;
> +                       end = cp+1;
> +               }
> +               rotator |= *cp++;
> +               while (rotator & 0x8000) {
> +                       bitshift++;
> +                       rotator <<= 1;
> +               }
> +               cmd->resp[0] = rotator >> 8;
> +               leftover = rotator;
> +       } else {
> +               cmd->resp[0] = *cp++;
>        }
> -
> -       cmd->resp[0] = *cp++;
>        cmd->error = 0;
>
>        /* Status byte: the entire seven-bit R1 response.  */
>        if (cmd->resp[0] != 0) {
>                if ((R1_SPI_PARAMETER | R1_SPI_ADDRESS
> -                                       | R1_SPI_ILLEGAL_COMMAND)
> +                                     | R1_SPI_ILLEGAL_COMMAND)
>                                & cmd->resp[0])
>                        value = -EINVAL;
>                else if (R1_SPI_COM_CRC & cmd->resp[0])
> @@ -339,12 +356,45 @@ checkstatus:
>         * SPI R5 == R1 + data byte; IO_RW_DIRECT
>         */
>        case MMC_RSP_SPI_R2:
> -               cmd->resp[0] |= *cp << 8;
> +               /* read the next byte */
> +               if (cp == end) {
> +                       value = mmc_spi_readbytes(host, 1);
> +                       if (value < 0)
> +                               goto done;
> +                       cp = host->data->status;
> +                       end = cp+1;
> +               }
> +               if (bitshift) {
> +                       rotator = leftover << 8;
> +                       rotator |= *cp << bitshift;
> +                       cmd->resp[0] |= (rotator & 0xFF00);
> +               } else {
> +                       cmd->resp[0] |= *cp << 8;
> +               }
>                break;
>
>        /* SPI R3, R4, or R7 == R1 + 4 bytes */
>        case MMC_RSP_SPI_R3:
> -               cmd->resp[1] = get_unaligned_be32(cp);
> +               rotator = leftover << 8;
> +               cmd->resp[1] = 0;
> +               for (i = 0; i < 4; i++) {
> +                       cmd->resp[1] <<= 8;
> +                       /* read the next byte */
> +                       if (cp == end) {
> +                               value = mmc_spi_readbytes(host, 1);
> +                               if (value < 0)
> +                                       goto done;
> +                               cp = host->data->status;
> +                               end = cp+1;
> +                       }
> +                       if (bitshift) {
> +                               rotator |= *cp++ << bitshift;
> +                               cmd->resp[1] |= (rotator >> 8);
> +                               rotator <<= 8;
> +                       } else {
> +                               cmd->resp[1] |= *cp++;
> +                       }
> +               }
>                break;
>
>        /* SPI R1 == just one status byte */
> @@ -720,6 +770,8 @@ mmc_spi_readblock(struct mmc_spi_host *h
>        struct spi_device       *spi = host->spi;
>        int                     status;
>        struct scratch          *scratch = host->data;
> +       unsigned int            bitshift;
> +       u8                      leftover;
>
>        /* At least one SD card sends an all-zeroes byte when N(CX)
>         * applies, before the all-ones bytes ... just cope with that.
> @@ -731,38 +783,60 @@ mmc_spi_readblock(struct mmc_spi_host *h
>        if (status == 0xff || status == 0)
>                status = mmc_spi_readtoken(host, timeout);
>
> -       if (status == SPI_TOKEN_SINGLE) {
> -               if (host->dma_dev) {
> -                       dma_sync_single_for_device(host->dma_dev,
> -                                       host->data_dma, sizeof(*scratch),
> -                                       DMA_BIDIRECTIONAL);
> -                       dma_sync_single_for_device(host->dma_dev,
> -                                       t->rx_dma, t->len,
> -                                       DMA_FROM_DEVICE);
> -               }
> +       if (status < 0) {
> +               dev_dbg(&spi->dev, "read error %02x (%d)\n", status, status);
> +               return status;
> +       }
>
> -               status = spi_sync(spi, &host->m);
> +       /* The token may be bit-shifted...
> +        * the first 0-bit precedes the data stream.
> +        */
> +       bitshift = 7;
> +       while (status & 0x80) {
> +               status <<= 1;
> +               bitshift--;
> +       }
> +       leftover = status << 1;
>
> -               if (host->dma_dev) {
> -                       dma_sync_single_for_cpu(host->dma_dev,
> -                                       host->data_dma, sizeof(*scratch),
> -                                       DMA_BIDIRECTIONAL);
> -                       dma_sync_single_for_cpu(host->dma_dev,
> -                                       t->rx_dma, t->len,
> -                                       DMA_FROM_DEVICE);
> -               }
> +       if (host->dma_dev) {
> +               dma_sync_single_for_device(host->dma_dev,
> +                               host->data_dma, sizeof(*scratch),
> +                               DMA_BIDIRECTIONAL);
> +               dma_sync_single_for_device(host->dma_dev,
> +                               t->rx_dma, t->len,
> +                               DMA_FROM_DEVICE);
> +       }
>
> -       } else {
> -               dev_dbg(&spi->dev, "read error %02x (%d)\n", status, status);
> +       status = spi_sync(spi, &host->m);
>
> -               /* we've read extra garbage, timed out, etc */
> -               if (status < 0)
> -                       return status;
> +       if (host->dma_dev) {
> +               dma_sync_single_for_cpu(host->dma_dev,
> +                               host->data_dma, sizeof(*scratch),
> +                               DMA_BIDIRECTIONAL);
> +               dma_sync_single_for_cpu(host->dma_dev,
> +                               t->rx_dma, t->len,
> +                               DMA_FROM_DEVICE);
> +       }
>
> -               /* low four bits are an R2 subset, fifth seems to be
> -                * vendor specific ... map them all to generic error..
> +       if (bitshift) {
> +               /* Walk through the data and the crc and do
> +                * all the magic to get byte-aligned data.
>                 */
> -               return -EIO;
> +               u8 *cp = t->rx_buf;
> +               unsigned int len;
> +               unsigned int bitright = 8 - bitshift;
> +               u8 temp;
> +               for (len = t->len; len; len--) {
> +                       temp = *cp;
> +                       *cp++ = leftover | (temp >> bitshift);
> +                       leftover = temp << bitright;
> +               }
> +               cp = (u8 *) &scratch->crc_val;
> +               temp = *cp;
> +               *cp++ = leftover | (temp >> bitshift);
> +               leftover = temp << bitright;
> +               temp = *cp;
> +               *cp = leftover | (temp >> bitshift);
>        }
>
>        /* Omitt the CRC check for CID and CSD reads. There are some SDHC
>
> ---
> regards
>
> i. A. Wolfgang Mües
> --
> Auerswald GmbH & Co. KG
> Hardware Development
> Telefon: +49 (0)5306 9219 0
> Telefax: +49 (0)5306 9219 94
> E-Mail: Wolfgang.Mues@Auerswald.de
> Web: http://www.auerswald.de
>
> --------------------------------------------------------------
> Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
> Registriert beim AG Braunschweig HRA 13289
> p.h.G Auerswald Geschäftsführungsges. mbH
> Registriert beim AG Braunschweig HRB 7463
> Geschäftsführer: Dipl-Ing. Gerhard Auerswald
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Wolfgang Mües]

Will,

Am Mittwoch, 11. März 2009 schrieb Will Newton:
> <wolfgang.mues@auerswald.de> wrote:
> > From: Wolfgang Muees <wolfgang.mues@auerswald.de>
> >
> > o A very large subset of SD cards in the market send their
> >  responses and data non-byte-aligned. So add logic to the
> >  mmc spi driver to handle this mess.
>
> Are you sure about this?

Yes.

> Do you have any further references for this 
> or examples of cards that exhibit this problem?

Kingston. The 1 GByte SD card, and a 128 MByte microSD card. I have got some 
reports from other mmc spi users with the same problem.

The SD protocoll ist NOT byte-aligned. Messages are starting with a 
leading "0" bit. I think some chip vendors have adapted the SPI mode from SD 
mode and forgotten to do propper byte alignment. 

> Are you sure your SPI host controller is operating correctly?

Yes. My logic probe gives the same results as my spi host controller.
For some cards, you can see the bit offset is getting larger if the
controller on the SD card is getting more and more busy...

best regards
 
i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@Auerswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Will Newton]

On Wed, Mar 11, 2009 at 2:34 PM, Wolfgang Mües
<wolfgang.mues@auerswald.de> wrote:
> Will,
>
> Am Mittwoch, 11. März 2009 schrieb Will Newton:
>> <wolfgang.mues@auerswald.de> wrote:
>> > From: Wolfgang Muees <wolfgang.mues@auerswald.de>
>> >
>> > o A very large subset of SD cards in the market send their
>> >  responses and data non-byte-aligned. So add logic to the
>> >  mmc spi driver to handle this mess.
>>
>> Are you sure about this?
>
> Yes.
>
>> Do you have any further references for this
>> or examples of cards that exhibit this problem?
>
> Kingston. The 1 GByte SD card, and a 128 MByte microSD card. I have got some
> reports from other mmc spi users with the same problem.

Are they using the same host controller? Have you tried these cards
with a different host controller?

Are you clocking them particularly slow or fast?

> The SD protocoll ist NOT byte-aligned. Messages are starting with a
> leading "0" bit. I think some chip vendors have adapted the SPI mode from SD
> mode and forgotten to do propper byte alignment.
>
>> Are you sure your SPI host controller is operating correctly?
>
> Yes. My logic probe gives the same results as my spi host controller.
> For some cards, you can see the bit offset is getting larger if the
> controller on the SD card is getting more and more busy...

A logic probe may not display any signal integrity issues you might have.

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Wolfgang Mües]

Will,

Am Mittwoch, 11. März 2009 schrieb Will Newton:
> Are they using the same host controller? Have you tried these cards
> with a different host controller?

I have tried with 3 different spi host controllers.

> Are you clocking them particularly slow or fast?

400 KHz, 20 MHz and 25 MHz.

> A logic probe may not display any signal integrity issues you might have.

My "logic probe" is a 1 GHz leCroy DSO. 

I am doing this for money, and I am no amateur.

best regards
 
i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@Auerswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Will Newton]

On Wed, Mar 11, 2009 at 3:00 PM, Wolfgang Mües
<wolfgang.mues@auerswald.de> wrote:
> Will,
>
> Am Mittwoch, 11. März 2009 schrieb Will Newton:
>> Are they using the same host controller? Have you tried these cards
>> with a different host controller?
>
> I have tried with 3 different spi host controllers.
>
>> Are you clocking them particularly slow or fast?
>
> 400 KHz, 20 MHz and 25 MHz.
>
>> A logic probe may not display any signal integrity issues you might have.
>
> My "logic probe" is a 1 GHz leCroy DSO.
>
> I am doing this for money, and I am no amateur.

Ok, sure, but these are things that are best put in your changleogs so
people can understand what hardware is problematic and how it is
proven.

I have not seen these problems or seen them reported by others.
Hopefully they will speak up and confirm your results.

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Wolfgang Mües]

Will,

Am Mittwoch, 11. März 2009 schrieb Will Newton:
> I have not seen these problems or seen them reported by others.

Yes, it is hard to believe that such a design error is present in today SD 
cards. But spi mode is used only by some devices which do not have a SD host 
controller on board.

I know a commercial FAT/SD card software package, and I found that inside 
their spi driver, there is support for non-byte-aligned cards too. So I am 
not the only one who has knowlegde about this problem.

Should I send you one of these cards so you can verify this problem?

best regards
 
i. A. Wolfgang Mües
-- 
Auerswald GmbH & Co. KG
Hardware Development
Telefon: +49 (0)5306 9219 0
Telefax: +49 (0)5306 9219 94 
E-Mail: Wolfgang.Mues@Auerswald.de
Web: http://www.auerswald.de
 
--------------------------------------------------------------
Auerswald GmbH & Co. KG, Vor den Grashöfen 1, 38162 Cremlingen
Registriert beim AG Braunschweig HRA 13289
p.h.G Auerswald Geschäftsführungsges. mbH
Registriert beim AG Braunschweig HRB 7463
Geschäftsführer: Dipl-Ing. Gerhard Auerswald

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Will Newton]

On Wed, Mar 11, 2009 at 3:14 PM, Wolfgang Mües
<wolfgang.mues@auerswald.de> wrote:
> Will,
>
> Am Mittwoch, 11. März 2009 schrieb Will Newton:
>> I have not seen these problems or seen them reported by others.
>
> Yes, it is hard to believe that such a design error is present in today SD
> cards. But spi mode is used only by some devices which do not have a SD host
> controller on board.

I have found some older cards that do not work well with SPI mode, but
I had written of these as ancient relics (128Mb or less in capacity).
I was under the impression that more mobile devices are using SPI mode
these days so SPI mode was becoming more of a priority for
manufacturers.

> I know a commercial FAT/SD card software package, and I found that inside
> their spi driver, there is support for non-byte-aligned cards too. So I am
> not the only one who has knowlegde about this problem.
>
> Should I send you one of these cards so you can verify this problem?

I would be interested to know the manufacturer and model number of a
couple of examples certainly, that way hopefully the test would be
truly independent.

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[David Brownell]

On Wednesday 11 March 2009, Wolfgang Mües wrote:
> The SD protocoll ist NOT byte-aligned. Messages are starting with a 
> leading "0" bit. I think some chip vendors have adapted the SPI mode
> from SD mode and forgotten to do propper byte alignment. 

Please capture that information in comments somewhere, so the
next folk updating the driver won't have to be guessing as much
about the low-level protocol bugs that are being coped with.

Comments listing concrete examples of such cards (or even
just a compatibility list posted to an archived mailing
list so a websearch can find it) would be nice too.  Who
knows, maybe the vendors would even fix the next rev of
their silicon (or firmware, whatever).  ;)


> Am Mittwoch, 11. März 2009 schrieb Will Newton:
> > I have not seen these problems or seen them reported by others.
>
> Yes, it is hard to believe that such a design error is present in today SD
> cards. But spi mode is used only by some devices which do not have a SD
> host controller on board.

I think that's it exactly.  Some of the newer MMC-derived
specifications even desupported SPI mode, as I recall.

In practice, I can't see it going away for a very long time,
but mid- and high-end systems tend to have real MMC/SD/SDIO
controllers they use for media cards as well as eMMC and
other "managed NAND" solutions (iNAND etc); and presumably
CE-ATA isn't entirely a paper tiger.

- Dave

Re: [PATCH 7/7] mmc_spi: support for non-byte-aligned cards

[Robin Getz]

On Wed 11 Mar 2009 11:03, Will Newton pondered:
> On Wed, Mar 11, 2009 at 3:00 PM, Wolfgang Mües
> <wolfgang.mues@auerswald.de> wrote:
> > Will,
> >
> > Am Mittwoch, 11. März 2009 schrieb Will Newton:
> >> Are they using the same host controller? Have you tried these cards
> >> with a different host controller?
> >
> > I have tried with 3 different spi host controllers.
> >
> >> Are you clocking them particularly slow or fast?
> >
> > 400 KHz, 20 MHz and 25 MHz.
> >
> >> A logic probe may not display any signal integrity issues you might have.
> >
> > My "logic probe" is a 1 GHz leCroy DSO.
> >
> > I am doing this for money, and I am no amateur.
> 
> Ok, sure, but these are things that are best put in your changleogs so
> people can understand what hardware is problematic and how it is
> proven.
> 
> I have not seen these problems or seen them reported by others.
> Hopefully they will speak up and confirm your results.

We have seen the same issues, and have had various Blackfin users report the 
same with a select number of cards. (including Kingston cards that Wolfgang 
referenced).

A few (who also had ARM platforms) said they saw the same on different SPI 
controllers - so I don't think it is a Blackfin specific issue.

-Robin