-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, November 29, 2013 3:50 PM To: David Henningsson Cc: Lin, Mengdong; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] HD-Audio: How to reduce driver initializaton time if multiple codecs present on the bus?
At Fri, 29 Nov 2013 15:31:59 +0800, David Henningsson wrote:
2013-11-29 14:40, Takashi Iwai skrev:
At Fri, 29 Nov 2013 14:30:48 +0800, David Henningsson wrote:
2013-11-28 22:57, Lin, Mengdong skrev:
Hi Takashi,
We're trying to reduce the HD-A driver initialization time when more
than one codecs are connected to the bus, but are blocked.
Would you please share some advices on this?
Usually, there is one HD-A controller connecting to two codecs: one
on-board codec and one integrated display codec.
During initialization, the codecs are created and configured in a
serial way.
Creating a codec may cost 6~20ms, and then building controls make
cost about 15~30ms.
Sorry for interrupting, but I just wonder - I assume you have a maximum of 4 CPUs. Can't the other 3 CPUs be used to load other non-audio hardware in parallel instead? It sounds you're going to run into lock contention instead if you try to modify the same card from two threads simultaneously.
IIRC, PCI device probes are done sequentially because asynchronous probe caused too many troubles. And if it's a module, it's anyway more strictly serialized.
Okay. It just seems to me that from a bird's eye view that parallelizing module loading and pci probing would give us much bigger benefits than trying to parallellize internally in the snd-hda-intel driver.
Yeah, for a long run, this would be far benefit. But be warned, several attempts in the past failed due to weird hardwares :)
Btw, using a deferred azx_probe_continue (like we do if there's a firmware file), would one get more parallelization with other drivers? If so we could consider making that the default.
This sounds like a good idea as we have already that code. The patch would be just a few-liners.
If azx_probe_continue() is delayed, could user space get incomplete audio information after boot? I mean is it possible that azx_probe_continue() does not complete before user space check ALSA info?
Thanks Mengdong