[alsa-devel] [PATCH 7/8] ASoC: Add SPI support for WM8731

[Alan Horstmann]

On Monday 08 September 2008 14:52, you wrote:
> On Thu, Sep 04, 2008 at 11:48:29AM +0100, Alan Horstmann wrote:
> > I assume that spi_transfer sends bytes in order, from the tx_buf
> > position, and it seems clear that data[0] is the high byte that should go
> > first.  As msg[2] is u16 (why?), I would have thought that the byte at
> > &msg[0] would be the low byte on LE, high byte on BE so it would only be
> > correct on BE.
>
> Your analysis makes sense to me.
>
> > Changing the code to use
>
> ...
>
> > fixes the problem here.
>
> Could you supply a patch, please?

Attached and here inline is the small change we applied to ensure the byte 
order is correct in the _spi_write function.  Note we observed the spi bus 
with a fast Digital Oscilloscope, and could readily see the bytes were 
originally reversed in our case (AT91SAM9260).  Our build is set to LE, but I 
have no idea why the write should be fine on Blackfin-LE without this change.

With just this one change we have been successful in running the codec over 
spi.  At present we do have an issue with dapm during capture -nothing is 
being turned on!  Any pointers would be appreciated.

Alan

wm8731_spi_write_byte_order.patch

--- wm8731-orig.c	2008-09-08 17:16:52.000000000 +0100
+++ wm8731.c	2008-09-08 21:03:16.000000000 +0100
@@ -688,12 +688,13 @@
 {
 	struct spi_transfer t;
 	struct spi_message m;
-	u16 msg[2];
+	u8 msg[2];

 	if (len <= 0)
 		return 0;

-	msg[0] = (data[0] << 8) + data[1];
+	msg[0] = data[0];
+	msg[1] = data[1];

 	spi_message_init(&m);
 	memset(&t, 0, (sizeof t));

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wm8731_spi_write_byte_order.patch
Type: application/octet-stream
Size: 369 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20080908/b0d6f225/attachment.dll