On 05/06/2011 12:56 AM, Mike Frysinger wrote:
On Thu, May 5, 2011 at 13:52, Lars-Peter Clausen wrote:
Currently there is a special case for the ad1836 in the ASoC generic spi write functions, which swaps the upper and the lower byte for 4/12 transfers. This was done, because the 4/12 spi write function was added for the ad1836 for which all of the users are configured to use use 16-bit transfers. In order to be able to get rid of this special casing switch all users of ad1836 to 8-bit transfers.
16bit spi transfers are inherently less overhead than 8bit transfers. so if the codec supports it, we should use it rather than drop 16bit support everywhere because 8bit is simpler. am i missing something obvious ? -mike
At some point the codec driver used u16 for the type of the data to be transferred, so 16bit transfers where fine then. But at some point the driver was updated to use the snd_soc_cache infrastructure, which uses a u8[2] array for the data to be transferred.
The snd_soc_cache infrastructure has several helper functions for writing spi on a spi bus. The one used by the ad1836 was specifically added for the ad1836 and is special compared to the other spi helper functions in the regard that it swaps the upper and the lower byte of the to be transferred data. While this works on blackfin which is litte-endian this scheme will obviously fail on big-endian machines. Also this might not work for other codecs which want to reuse the same helper function.
And furthermore it disallows more generalization of the spi write functions in snd_soc_cache, which is done in the follow-up patches.
If we wanted to use 16-bit spi transfers we would have to add something generic to the do_spi_write function, which swaps the upper and the lower byte of each short to be transferred if the host is little-endian.
- Lars