2009-06-18 16:37:12     spidev Byte Ordering

2009-06-18 16:37:12     spidev Byte Ordering

Ben Matthews (UNITED STATES)

Message: 75998   

I'm using the spidev driver to send some simple 16bit commands to a DAC and having trouble with byte ordering. On older versions of the kernel (tested one from December, git hash d9cae196e2646c58abb1fa7959c333695eaa6768) the messages go out as expected with the MSB first. On newer kernels (from the end of May, git hash: 5165f860a03e9f19b387ba13c925831739305d0f) the bytes are swapped (possibly the whole word is mirrored, I'm not 100% sure). I've tried playing with the SPI_IOC_WR_LSB_FIRST ioctl, but it doesn't seem to make any difference in the data actually being clocked out. If I try to use the corresponding read call, I get zero by default (which is probably what we want).

Using debugfs, it looks like the driver is setting the controller to clock the data out MSB first (which is what we want).

Unfortunatly, on the scope it looks like things are flipped (running the newer kernel only).

Any ideas what may have changed or how to fix it? I've looked through the changes between the two kernels and don't see anything obvious.

Thanks

QuoteReplyEditDelete

2009-06-18 16:56:10     Re: spidev Byte Ordering

Mike Frysinger (UNITED STATES)

Message: 76001   

we dont really test 16bit transfers that often because so few devices actually operate that way.  looking at the functions in question though, i dont think they've really changed.  the 8bit and 16bit functions are kept separate.  you can see them as bfin_spi_u#_writer and such.

MSB setting shouldnt affect byte swapping in any way as that option simply says whether to clock from bit 0 to bit 15 or vice versa.

if you dont mind a little bit of compiling, you should be able to use git bisect to figure out the commit that broke things for you since you have a known working commit and a known failing commit.

QuoteReplyEditDelete

2009-06-19 15:41:02     Re: spidev Byte Ordering

Ben Matthews (UNITED STATES)

Message: 76058   

I did the bisect and found that both kernels behaved the same when compiled with the same environment. The original working kernel was given to me as a binary. The configuration hasn't changed significantly, which just leaves the toolchain. I assume that the working image I have was built with a toolchain from around the same time period. The toolchain I'm using is only about a week old since I had to rebuilt it to add wide character support. I'll try to confirm this theory by building the new kernel with the old toolchain (have to resolve some issues linking busybox with the old tools first) but in the mean time I was wondering if anything had changed that's likely to be causing my problems?

I think I may also try sending twice as many 8bit transfers w/o deasserting the chip select.

Thanks

QuoteReplyEditDelete

2009-06-19 15:48:12     Re: spidev Byte Ordering

Mike Frysinger (UNITED STATES)

Message: 76061   

that does sound weird.  the toolchain used to compile shouldnt affect this behavior in any way.

you should d/l the latest 2009R1 toolchain that is available in the toolchain project.