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.
��.n��������+%������w��{.n�����������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f