Re: HD-Audio: How to reduce driver initializaton time if multiple codecs present on the bus?

[Takashi Iwai <tiwai@suse.de>]

At Thu, 28 Nov 2013 14:57:22 +0000,
Lin, Mengdong wrote:
> 
> 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.
> So I had thought it's helpful to build controls for different codecs in parallel in function snd_hda_build_controls(), as we did in driver suspend/resume.
> 
> But the test shows this doesn't work:
> 
> (1)     Using a workqueue without WQ_UNBOUND, the work items, which calls snd_hda_codec_build_controls(), are processed one after one

You have to synchronize before starting building PCMs and controls.
That is, you can parallelize snd_hda_codec_configure() calls, but the
rest has to be serialized.

> (I think because there is no explicit sleep in the work function). So the total time does not change.
> 
> 
> 
> (2)     Using an unbouned work queue for the bus or using separate kthreads for each codec, the work items for different codecs are processed in parallel.
> 
> However, the total time is still the sum of two codec as that without parallel.
> I think that because snd_hda_codec_read() are used during initialization, the command execution on bus is serialized in the low level.
> So even if we parallel initializing two codecs in high level, commands on bus are still processed one by one so the total time cannot reduce.

If the bottleneck is the time consumed to perform the whole verbs,
then it's unavoidable, of course.  You have only a single street no
matter how many cars are running.

So, you must analyze the problem before starting such optimizations.
For example, put tracepoints to measure the time consumption.

> We're blocked here. Is there any other means to reduce the time?

Reduce the amount of init verbs.

So far, the driver tries to initialize all things properly by itself
without trusting the default values the codec sets (e.g. setting the
amp to mute, selecting the selector to 0).  These verbs are often
redundant.

But, assuming some default values is of course risky, if the hardware
doesn't follow it by some reason -- or if the same path is executed in
a different situation like runtime PM.


Takashi