Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 9 Dec 2009, Mark Brown wrote:

> > How long does it take to bring down the entire embedded audio 
> > subsystem?  And how critical is the timing for typical systems?
> 
> Worst case is about a second for both resume and suspend which means two
> seconds total but it's very hardware dependant.  

I would seriously suggest just looking at the code itself.

Maybe the code is just plain sh*t? If we're talking embedded audio, we're 
generally talking SoC chips (maybe some external audio daughtercard), and 
quite frankly, it sounds to me like you're just wasting your own time. 
There is no way that kind of hardware really needs that much time.

We should not design the device infrastructure for crap coding. 

Now, I can easily see one-second delays in code that simply has never been 
thought about or cared about it. We used to have things like that in the 
serial code where just probing for non-existent serial ports took half a 
second per port because there was a timeout. 

But christ, using that as an argument for "we should do things 
asynchronously" sounds like a crazy idea. Why not just take a hard look at 
the driver in question, asking hard questions like "does it really need to 
do something horrible like that"?

Because bad coding is much more likely to be the real reason.

			Linus