On Tue, 25 Feb 2014 01:22:04 +0000, Mark Brown wrote:
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.
Yes, true. Good point.
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.
I have to agree, the variation won't be great. If it were then you'd see problems for example when keeping a device awake for prolonged periods and during fluctuations in temperature. As far as I'm aware issues like this have not been experienced with this device so I think it's safe to make this a one time thing at startup.