[alsa-devel] HD-Audio: How to reduce driver initializaton time if multiple codecs present on the bus?

[Lin, Mengdong]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Friday, November 29, 2013 3:50 PM
> To: David Henningsson
> Cc: Lin, Mengdong; alsa-devel at 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