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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
