[alsa-devel] [PATCH] ad1838/cs4231 -- fix MCE timeout upon initial load

[Rene Herman]

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.