On Mon, Feb 24, 2014 at 01:57:53PM +0000, Opensource [Adam Thomson] wrote:
anyway. I'd be tempted to keep it simple and just make those registers volatile, then you know it will work as expected, at least for the time being until a
That breaks suspend and resume without further work - for suspend and resume we generally rely on restoring the register cache to restore the current settings but if a register is volatile it won't be cached so will go back to the hardware defaults after suspend. The ability to avoid I2C traffic is partly just a nice side effect (though it was needed on devices that don't have readback), the main thing these days is that controls get efficient suspend and resume handling for free.
Refactoring the offset correction to happen once on startup would solve the issue since the cache could just be bypassed, though you are likely to find that there is some run to run variation for the callibration due to effects like thermal variation and simple measurement errors. Still, the effects are typically very small.