[alsa-devel] [PATCH] ad1848 and cs4231 busy loop replacement
Rene Herman
rene.herman at gmail.com
Mon Sep 10 13:54:26 CEST 2007
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.
More information about the Alsa-devel
mailing list