-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, November 29, 2013 4:08 PM To: Lin, Mengdong Cc: David Henningsson; 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 08:05:35 +0000, Lin, Mengdong wrote:
-----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?
Not impossible. But then user-space should be triggered in event driven way by udev or such.
Hi Takashi/David,
So is it okay to defer azx_probe_continue() by default?
If yes, is it also necessary to defer snd_card_create() at the end of azx_probe_continue()? So user space can only see the sound card when azx_probe_continue() completes.
We've checked the driver initialization time, the bottleneck is the bus. In three major three time-consuming functions, snd_hda_codec_new, azx_codec_configure, and snd_hda_codec_build_controls, almost all the time is spent in codec_exec_verb().
So deferring azx_probe_continue() will be more helpful to reduce the initialization time and get more parallelization with other drivers.
Thanks Mengdong