[alsa-devel] [PATCH 1/2] ASoC: Remove byte swap in 4x12 SPI write

Lars-Peter Clausen lars at metafoo.de
Wed May 11 20:02:26 CEST 2011


On 05/11/2011 10:48 AM, Mark Brown wrote:
> On Wed, May 11, 2011 at 10:35:37AM -0700, Lars-Peter Clausen wrote:
> 
>> I've probably not properly explained the problem in my previous patch.
>> endian.
> 
> This is totally unrelated to your previous patch (as is the last one),
> I'm doing some different work on the physical I/O code and frankly
> hadn't thought you had any patches you hadn't resent and got applied
> yet.

Ok, since the patches were basically identical to the patches I send the other
week, I thought they were related.

> 
>> The problem is due to how 16-bit SPI transfers work on linux and how
>> snd_soc_cache stores the data which is going to be send.
> 
> We shouldn't be using 16 bit transfers at all, that's insane.  If the
> board has gone and done that that's silly, and if drivers are relying
> on the board having done that then it's at best incredibly fragile.
> There certainly aren't any which check the word size.
> 
>> ASoC though uses a u8 array. So when this array is interpreted as a u16 array
>> instead the values will be in big-endian. As a result using 16-bit spi
>> transfers on a little-endian machine will send out the data byte-swapped.
>> Your patch does not change since.
> 
> Right, if the SPI controllers are being set up with anything other than
> 8 bit word sizes in transfers this is going to fall over.  However,
> since we can't rely on SPI controllers supporting anything other than 8
> bit transfers and we don't currently have a sensible way of negotiating
> the word size with the controller driver anyway I'd really expect us to
> only ever use 8 bit words without a bunch more infrastructure work.

Ok, could you comment again on this[1] then?
Because what the patch did was switching the codec from 16-bit to 8-bit
transfers, because of the issues described above.

Thanks
- Lars

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-May/039469.html



More information about the Alsa-devel mailing list