[alsa-devel] [PATCH] ad1838/cs4231 -- fix MCE timeout upon initial load
rene.herman at gmail.com
Wed Sep 19 04:48:28 CEST 2007
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
> 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
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 &
> Good idea, I've done that.
No goto? :-)
More information about the Alsa-devel