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.
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.
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.