On Thu, Oct 8, 2009 at 06:01, Mark Brown wrote:
On Wed, Oct 07, 2009 at 08:27:56PM -0400, Mike Frysinger wrote:
i dont think the soc-cache could be used currently by the ad1836 as it doesnt use a 7/9 split with the address/data. it uses like 6/10 (4 addr bits, one bit for read/write, one bit is always 0, and 10 data bits). guessing the write bit can be considered part of the addr as the read always comes from the cache, but that still gives us 5/10 split. maybe a new 6/10 set of funcs should be added ...
That's the idea - add new functions for any new register formats.
i'll add a tracker item to get the ad codecs converted to soc-cache when possible and that'll naturally address the SPI dependency
snd_soc_7_9_write() looks like it does a little more bit work than it needs to ? if data is declared as a u16, then you have: u16 data = (reg << 9) | (value & 0x01ff); this is what the ad1836 driver does now for its data split.
Probably. I'd need to check but I believe that's there to handle endianness variations in the host, though a cpu_to_ in what you have above ought to be able to take care of that. The code was cut'n'pasted from what was in the drivers already.
true ... being little endian sometimes makes you forget about these things ;). the ad1836 codec probably doesnt work on BE systems.
in the mean time, rather than adding #ifdef to the codec driver, we could create a local header like "bus-stubs.h" that stubs all the relevant functions to an error value. then all codec drivers that dont use soc-cache can use that instead and the only change needed is to add: #include "bus-stubs.h"
I'm not sure I feel up to doing that locally in ASoC rather than in the relevant subsystems.
i dont feel like convincing subsystem maintainers that this is a good idea for all consumers of SPI/I2C, especially since i'm not convinced myself. we'll just go the soc-cache route and not worry about it. -mike