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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
