Skip to contentSkip to conversation

mpc52xx_psc_spi: fix block transfer

PATCH In review David Brownell 2 participants 3 messages Jul 27, 2008 – Jul 28, 2008 2 messages not in the archive SPI

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mpc52xx_psc_spi: fix block transfer

From: Luotao Fu <[email protected]>

The block transfer routine in the mpc52xx psc spi driver misinterpret the datasheet. According to the processor datasheet the chipselect is held as long as the EOF is not written. Theoretically block of any sizes can be transferred in this way. The old routine however writes an EOF after every word, which has the size of size_of_word. This makes the transfer slow. Also fixed some duplicate code.

---
 drivers/spi/mpc52xx_psc_spi.c |   22 +++++++---------------
 1 file changed, 7 insertions(+), 15 deletions(-)
drivers/spi/mpc52xx_psc_spi.c +7 -15
@@ -148,7 +148,6 @@ static int mpc52xx_psc_spi_transfer_rxtx
 	unsigned rfalarm;
 	unsigned send_at_once = MPC52xx_PSC_BUFSIZE;
 	unsigned recv_at_once;
-	unsigned bpw = mps->bits_per_word / 8;
 
 	if (!t->tx_buf && !t->rx_buf && t->len)
 		return -EINVAL;
@@ -164,22 +163,15 @@ static int mpc52xx_psc_spi_transfer_rxtx
 		}
 
 		dev_dbg(&spi->dev, "send %d bytes...\n", send_at_once);
-		if (tx_buf) {
-			for (; send_at_once; sb++, send_at_once--) {
-				/* set EOF flag */
-				if (mps->bits_per_word
-						&& (sb + 1) % bpw == 0)
-					out_8(&psc->ircr2, 0x01);
+		for (; send_at_once; sb++, send_at_once--) {
+			/* set EOF flag before the last word is sent */
+			if (send_at_once == 1)
+				out_8(&psc->ircr2, 0x01);
+
+			if (tx_buf)
 				out_8(&psc->mpc52xx_psc_buffer_8, tx_buf[sb]);
-			}
-		} else {
-			for (; send_at_once; sb++, send_at_once--) {
-				/* set EOF flag */
-				if (mps->bits_per_word
-						&& ((sb + 1) % bpw) == 0)
-					out_8(&psc->ircr2, 0x01);
+			else
 				out_8(&psc->mpc52xx_psc_buffer_8, 0);
-			}
 		}
 
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

A message that is not in the archive (sent off-list or not yet received): 200807271522.05967.david-b-yBeKhBN/[email protected]

#2 lore raw
Quoted 11 lines · On Sun, 27 Jul 2008 15:22:05 -0700 David Brownell…

From: Luotao Fu <[email protected]>

The block transfer routine in the mpc52xx psc spi driver misinterpret the datasheet. According to the processor datasheet the chipselect is held as long as the EOF is not written. Theoretically block of any sizes can be transferred in this way. The old routine however writes an EOF after every word, which has the size of size_of_word. This makes the transfer slow. Also fixed some duplicate code.

The patch applies to 2.6.25 and 2.6.26. Should we backport it?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

A message that is not in the archive (sent off-list or not yet received): 20080727194055.7d3b839d.akpm-de/[email protected]

#4 lore raw
Quoted 11 lines · Andrew Morton
Quoted 9 lines · On Sun, 27 Jul 2008 15:22:05 -0700 David Brownell…

From: Luotao Fu <[email protected]>

The block transfer routine in the mpc52xx psc spi driver misinterpret the datasheet. According to the processor datasheet the chipselect is held as long as the EOF is not written. Theoretically block of any sizes can be transferred in this way. The old routine however writes an EOF after every word, which has the size of size_of_word. This makes the transfer slow. Also fixed some duplicate code.

Quoted 4 lines
Quoted 2 lines

The patch applies to 2.6.25 and 2.6.26. Should we backport it?

Sounds like someone already did the backport! The issue would be whether it should be merged to 2.6.26-stable?

Getting the chipselect wrong like this is a fairly big deal; the protocol is wacked, many chips won't know what to do with lots of individual words, or will do the wrong thing.

I'd vote for making this widely available.

- Dave

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/