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

[Takashi Iwai]

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.


Takashi