On 09/19/2007 03:27 AM, Trent Piepho wrote:
On the other hand, cpu_relax() is totally different. It's basically a hint to the processor to lower the clock speed/power consumption or give resources to a sibling virtual processor in hyper-threading. i.e., it's ok to call cpu_relax() from an interrupt or while atomic.
Might be a good idea in the non-sleeping busy loops, like the one in snd_ad1848_wait(), but I bet the udelay() already does that.
It does (when using the TSC).
The original idea was to make this first waiting longer than loop granularity. 7ms before the loop than 1ms granularity inside the loop. Rene Herman was against it so he changed it to be the same as 1ms inside the loop.
Well, at that time, it still was first the 1 and then a full 250 -- or at least in my 2.6.22.x schedule_timeout_interruptible() version that actually scheduled...
With the delay time being dependent on sample rate, and with different chips being considerably faster than others, picking a good value for the first iteration is complicated. If one could avoid 70 ms of busy looping in the kernel by doing so, then that might be worth it. But we don't busy loop, just poll once per ms (even less when HZ<1000), so it seems that there is very little to gain here to justify the extra complexity.
Quite -- I plan on being around sound/isa/ for some time and am as such also already concerned with maintainability. If there's one thing I do know, it's that obviousness is an extremely important factor in that. So if the datasheet and hardware say 5 sample periods are enough, so be they...
Break this long line. You may calculate "regsel & AD1848_CALIB_IN_PROGRESS"
Good idea, I've done that.
No goto? :-)
Rene.