[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 4:08 PM
> To: Lin, Mengdong
> Cc: David Henningsson; 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 08:05:35 +0000,
> Lin, Mengdong wrote:
> >
> > > -----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?
> 
> 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