Rene wrote:
As you say, the next loop is waiting for the auto-calibration bit to go down again, so here we should be waiting (the maximum time needed) for it to come up after dropping the MCE bit. You do a msleep(7), which I assume is derived (somehow...) from the 384 cycles mentioned in the spec, at 48kHz, but that's the time the auto-calibration bit will stay up after _having_ come up.
On page 24 of the AD1848K spec (2nd column, near top) we have:
Clear the Mode Change Enable (MCE) bit
The Autocalibrate-In-Progrss (ACI) bit will transition from LO to HI within 5 sample periods. [ ... ]
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.
I tested on the AD1848 before I posted it. The 7ms delay was never enough for auto-calibration to complete. Even at 48kHz, tens of waiting loops iterations happened on my SC-6000. Tens of waiting loops is much less than 1 jiffy, and msleep(2) is 2 jiffies. Och, and my AD1848 returns 0xA revision which means it is AD1848K despite it is marked as AD1848 only.
fine. Also delaying for 1ms in cs2431 would be fine by me as well...
I tested this on SPARC cs4231. The 2ms and 1ms gives the same results which may be attributed to kernel timer resolution (2 jiffies for msleep(1) and msleep(2)). It was enough for the whole autocalibration (no waiting loop iterations at 48kHz). I got 2.8ms delay at 48kHz when I calculated it from the specs. I will retest it with kernel set to 1000 Hz to confirm if the 2ms is too long (it should not be we are below kernel timer resolution).
I will post SPARC cs4231 patch (with sleep and improved waiting) when Takashi will say if the kernel or alsa version of the driver is correct.
Rene, please test this patch on the cs4231 codec.
Given that the only difference is that I wait less, yours would've worked as well -- thanks for looking into this! And could you viceversa test this on AD1848 and perhaps resubmit if you agree?
Thanks, Krzysztof