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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
