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));
Attachment:
wm8731_spi_write_byte_order.patch
Description: Binary data
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
