Re: [PATCH] ad1848 and cs4231 busy loop replacement

[Rene Herman <rene.herman@gmail.com>]

On 09/10/2007 09:08 AM, Krzysztof Helt wrote:

> Rene wrote:

>> Which seems to be saying that we should be waiting for only 5 cycles at
>> that point. With the slowest (!) possible sampling rate of 5.5125 kHz 
>> that would mean 907 us, or sligtly under 1 ms.
>> 
> It does not matter. If you have to wait for the start of the 
> auto-calibration then for the end of auto-calibration you may as well 
> wait for the end of the auto-calibration only (unless you want to follow 
> the auto-calibration to the very single clock pulse ;-). The delay here 
> is simple to assure that auto-calibration started (and probably is 
> already under way). It may be longer then the start but it should not be 
> longer than whole auto-calibration.
> 
> I simply tried to do as long msleep as possible to allow other tasks 
> using CPU and decrease number of waiting loop iterations.

Well, no, sorry, but I consider that to be completely breaking the logic of 
the code. One line after this bit, we're doing the "wait for calibration to 
finish" loop (and already schedule ourselves away while doing so, for 250ms 
no less) meaning that at this point we should only wait long enough to be 
guaranteed that the ACI bit reflects reality -- those 5 cycles.

Your: wait unconditionally until calibration _nearly_ done, then go wait for 
it for 250 ms to be really done.

Mine: wait unconditionally until calibration has started, then go wait for 
it for 250 ms to finish.

Really -- please just do the 1 ms delay for ad1848 and either no delay or 
the same 1 ms for cs4231 if you want to keep them in sync (and the comment 
explaining why it's 1 ms). I don't particularly care about mdelay versus 
msleep here (although a mere 1 ms fits mdelay better) but your setup is 
pointlessly obscuring the code-flow.

Rene.